On Tue, Aug 16, 2011 at 11:24 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > There is the question if one should be allowed to tune the *_page_costs at > all. If I am not missing something, it is possible to detect the correct > values programmatically and they do not change if you do not change the > hardware. Cache hit ratio is the real reason why they are currently so > important for tuning.
Unfortunately things a tad more complex than this picture. There are multiple levels of cache involved here. There's the Postgres buffer cache, the filesystem buffer cache, and then the raid controller or drives often have cache as well. Also the difference between seq_page_cost and random_page_cost is hiding another cache effect. The reason sequential reads are faster is twofold, there's no seek but also there's an increased chance the buffer is already in the filesystem cache due to having been prefetched. Actually it's hardly even probabilistic -- only every nth page needs to do i/o when doing sequential reads. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
