Re: index-only scans

From: Greg Stark <stark(at)mit(dot)edu>
To: Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "postgres(at)cybertec(dot)at" <postgres(at)cybertec(dot)at>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: index-only scans
Date: 2011-09-23 14:42:51
Message-ID: CAM-w4HNcFeaarhswyCEXUoQf+Tja+KibssOTbF+Q_ZgBGLA++g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 16, 2011 at 11:24 AM, Anssi Kääriäinen
<anssi(dot)kaariainen(at)thl(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2011-09-23 14:44:09 Re: Re: [BUGS] BUG #6189: libpq: sslmode=require verifies server certificate if root.crt is present
Previous Message Thom Brown 2011-09-23 14:37:12 Re: [pgsql-advocacy] Unlogged vs. In-Memory