On 10/13/07, Gokulakannan Somasundaram <gokul007@gmail.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.harris@enterprisedb.com
Edison, NJ 08837 | http://www.enterprisedb.com/
