On 10/13/07, Gokulakannan Somasundaram <[EMAIL PROTECTED]> 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 | [EMAIL PROTECTED] Edison, NJ 08837 | http://www.enterprisedb.com/ ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
