From: | "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com> |
---|---|
To: | "Gokulakannan Somasundaram" <gokul007(at)gmail(dot)com> |
Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Andreas Joseph Krogh" <andreak(at)officenet(dot)no>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Including Snapshot Info with Indexes |
Date: | 2007-10-13 12:23:13 |
Message-ID: | 36e682920710130523m26d8e0f0u83f8040efdb6e74c@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On 10/13/07, Gokulakannan Somasundaram <gokul007(at)gmail(dot)com> wrote:
> I accept that the indexes will be bigger in size for this approach. You
> might need more disk-space and you might need more memory to accomodate the
> same amount of information. But i think disk costs and memory costs have
> come down a lot, People can afford to buy more disk and memory. But the only
> fact that remains true is that the disk, the last mechanical device is slow
> in addressing Random I/Os. So this proposal is aimed at occupying more
> memory and disk space to reduce Random I/Os. Say, if we are accomodating 200
> tuples per index page in today's index(for a typical configuration), and as
> you said in the worst case (only one index field), we will be occupying 100
> tuples per index page. But we would take away probably 100 random I/Os (say
> with bitmap scan it reduces to 75). 1GB of memory is around $100 and 1GB of
> disk is around $1. But one hour of Performance tuner would cost around $200
> :)). So that's the trade-off for the enterprises, if they want to shift
> between the two indexes.
I disagree. Even with the latest on-disk size enhancements, Postgres
still has a substantially larger on-disk footprint than pretty much
every other database. Like it or not, additional I/O costs are not
something that should just be dismissed.
Disregarding fundamental database issues (like increased I/O) leads me
to believe that you don't have much experience tuning databases. As I
have a bit of experience adding visibility to the indexes, I stand
behind DSM. From an analytical standpoint, and given Postgres' MVCC
design, it would be hard to beat a properly designed DSM in this area.
--
Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
EnterpriseDB Corporation | fax: 732.331.1301
499 Thornall Street, 2nd Floor | jonah(dot)harris(at)enterprisedb(dot)com
Edison, NJ 08837 | http://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2007-10-13 12:26:37 | Re: Including Snapshot Info with Indexes |
Previous Message | Gokulakannan Somasundaram | 2007-10-13 12:14:12 | Re: Including Snapshot Info with Indexes |
From | Date | Subject | |
---|---|---|---|
Next Message | Jonah H. Harris | 2007-10-13 12:26:37 | Re: Including Snapshot Info with Indexes |
Previous Message | Gokulakannan Somasundaram | 2007-10-13 12:14:12 | Re: Including Snapshot Info with Indexes |