Hello.
I did read and AFAIR sometimes responded on this long discussions. The
main point for me is that many DBAs dont want to have even more random
plans with postgresql knowing what's in memory now and using this
information directly in runtime. I also think this point is valid.
What I would like to have is to force some relations to be in memory by
giving them fixed part of shared buffers and to tell postgresql they are
in memory (lowering page costs) to have fixed optimal plans.
Best regards, Vitalii Tymchyshyn.
19.09.11 14:57, Cédric Villemain написав(ла):
2011/9/19 Vitalii Tymchyshyn<tivv00@xxxxxxxxx>:
17.09.11 23:01, Stefan Keller написав(ла):
* more... ?
What I miss from my DB2 UDB days are buffer pools. In PostgreSQL terms this
would be part of shared buffers dedicated to a relation or a set of
relations. When you have a big DB (not fitting in memory) you also usually
want some small tables/indexes be in memory, no matter what other load DB
has.
Complimentary features are:
1) Relations preloading at startup - ensure this relation are in memory.
you can use pgfincore extension to achieve that, for the OS cache. It
does not look interesting to do that for shared_buffers of postgresql
(the subject has been discussed and can be discussed again, please
check mailling list archieve first)
2) Per buffer pool (or relation) page costs - tell it that this
indexes/tables ARE in memory
you can use tablespace parameters (*_cost) for that, it has been
rejected for tables in the past.
I did propose something to start to work in this direction.
See "[WIP] cache estimates, cache access cost" in postgresql-hackers
mailling list.
This proposal let inform the planner of the table memory usage and
take that into account.
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
