From: | Vitalii Tymchyshyn <tivv00(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: reducing random_page_cost from 4 to 2 to force index scan |
Date: | 2011-05-24 09:12:34 |
Message-ID: | 4DDB7682.9040402@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hello.
As of me, all this "hot" thing really looks like uncertain and dynamic
enough.
Two things that I could directly use right now (and they are needed in
pair) are:
1)Per-table/index/database bufferpools (split shared buffer into parts,
allow to specify which index/table/database goes where)
2)Per-table/index cost settings
If I had this, I could allocate specific bufferpools for tables/indexes
that MUST be hot in memory and set low costs for this specific tables.
P.S. Third thing, great to have to companion this two is "Load on
startup" flag to automatically populate bufferpools with fast sequential
read, but this can be easily emulated with a statement.
Best regards, Vitalii Tymchyshyn
From | Date | Subject | |
---|---|---|---|
Next Message | Cédric Villemain | 2011-05-24 11:16:44 | Re: Hash Anti Join performance degradation |
Previous Message | Craig Ringer | 2011-05-24 05:53:00 | Re: Hash Anti Join performance degradation |