tv@fuzzy.cz wrote:
> Anyway I'm not an expert in this field, but AFAIK something like this
> already happens - btw that's the purpose of effective_cache_size.
effective_cache_size probably doesn't do as much as you suspect. It is
used for one of the computations for whether an index is small enough
that it can likely be read into memory efficiently. It has no impact on
caching decisions outside of that.
As for the ideas bouncing around here for tinkering with
random_page_size more automatically, I have a notebook with about a
dozen different ways to do that I've come up with over the last few
years. The reason no work can be done in this area is because there are
no standardized benchmarks of query execution in PostgreSQL being run
regularly right now. Bringing up ideas for changing the computation is
easy; proving that such a change is positive on enough workloads to be
worth considering is the hard part. There is no useful discussion to be
made on the hackers list that doesn't start with "here's the mix the
benchmarks I intend to test this new model against".
Performance regression testing for the the query optimizer is a giant
pile of boring work we get minimal volunteers interested in. Nobody
gets to do the fun model change work without doing that first though.
For this type of change, you're guaranteed to just be smacking around
parameters to optimize for only a single case without some broader
benchmarking context.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books