> On Thu, Apr 14, 2011 at 1:26 AM, Tomas Vondra <t...@fuzzy.cz> wrote: >> Workload A: Touches just a very small portion of the database, to the >> 'active' part actually fits into the memory. In this case the cache hit >> ratio can easily be close to 99%. >> >> Workload B: Touches large portion of the database, so it hits the drive >> very often. In this case the cache hit ratio is usually around RAM/(size >> of the database). > > You've answered it yourself without even realized it. > > This particular factor is not about an abstract and opaque "Workload" > the server can't know about. It's about cache hit rate, and the server > can indeed measure that.
OK, so it's not a matter of tuning random_page_cost/seq_page_cost? Because tuning based on cache hit ratio is something completely different (IMHO). 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. But I'm afraid there might be serious fail cases where the current model works better, e.g. what if you ask for data that's completely uncached (was inactive for a long time). But if you have an idea on how to improve this, great - start a discussion in the hackers list and let's see. regards Tomas -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
