Horton

Re: Slow count(*) again...

Sam Gendler <sgendler@ideasculptor.com>

View thread
From: Samuel Gendler <sgendler@ideasculptor.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: Joshua Tolley <eggyknap@gmail.com>, Craig Ringer <craig@postnewspapers.com.au>, mladen.gogala@vmsinfo.com, Neil Whelchel <neil.whelchel@gmail.com>, "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Date: 2010-10-12T03:58:45Z
Lists: pgsql-hackers, pgsql-performance 
On Mon, Oct 11, 2010 at 7:19 PM, Greg Smith <greg@2ndquadrant.com> wrote:
>
>
> This is a problem for the operating system to solve, and such solutions out
> there are already good enough that PostgreSQL has little reason to try and
> innovate in this area.  I routinely see seq scan throughput double on Linux
> just by tweaking read-ahead from the tiny defaults to a sane value.
>

I spent some time going through the various tuning docs on the wiki whie
bringing some new hardware up and I can't remember seeing any discussion of
tweaking read-ahead at all in the normal performance-tuning references.  Do
you have any documentation of the kinds of tweaking you have done and its
effects on different types of workloads?