Re: Slow count(*) again... - Mailing list pgsql-performance

From Greg Smith
Subject Re: Slow count(*) again...
Date
Msg-id [email protected]
Whole thread Raw
In response to Re: Slow count(*) again...  (Joshua Tolley <[email protected]>)
Responses Re: Slow count(*) again...
List pgsql-performance
Joshua Tolley wrote:
> It was asserted that reading bigger chunks would help performance; a response
> suggested that, at least in Linux, setting readahead on a device would
> essentially do the same thing. Or that's what I got from the thread, anyway.
> I'm interested to know how similar performance might be between the large
> block size case and the large readahead case.

Large read-ahead addresses the complaint here (bulk reads are slow) just
fine, which is one reason why this whole topic isn't nearly as
interesting as claimed.  Larger chunk sizes in theory will do the same
thing, but then you're guaranteed to be reading larger blocks than
necessary in all cases.  The nice thing about a good adaptive read-ahead
is that it can target small blocks normally, and only kick into heavy
read-ahead mode when the I/O pattern justifies it.

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.

--
Greg Smith, 2ndQuadrant US [email protected] Baltimore, MD
PostgreSQL Training, Services and Support  www.2ndQuadrant.us
Author, "PostgreSQL 9.0 High Performance"    Pre-ordering at:
https://www.packtpub.com/postgresql-9-0-high-performance/book


pgsql-performance by date:

Previous
From: Scott Carey
Date:
Subject: Re: Slow count(*) again...
Next
From: Scott Carey
Date:
Subject: Re: Slow count(*) again...