Horton

Re: index-only scans

Greg Stark <stark@mit.edu>

View thread
From: Greg Stark <stark@mit.edu>
To: Anssi Kääriäinen <anssi.kaariainen@thl.fi>
Cc: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, "postgres@cybertec.at" <postgres@cybertec.at>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2011-09-23T14:42:51Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Reduce the alignment requirement of type "name" from int to char, and arrange

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