pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Greg Smith <greg@2ndquadrant.com>
To: Joshua Tolley <eggyknap@gmail.com>
Cc: Craig Ringer <craig@postnewspapers.com.au>
Cc: mladen.gogala@vmsinfo.com, Neil Whelchel <neil.whelchel@gmail.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Subject: Re: Slow count(*) again...
Date: Mon, 11 Oct 2010 22:19:04 -0400
Message-ID: <4CB3C598.2010302@2ndquadrant.com> (raw)
In-Reply-To: <4cb25a0e.2a978e0a.7797.33d6@mx.google.com>
References: <201010091626.18636.neil.whelchel@gmail.com>
	<4CB11CC7.8070300@vmsinfo.com>
	<4CB167CA.9070109@postnewspapers.com.au>
	<4CB1F46E.80205@vmsinfo.com>
	<4CB2410C.6010603@postnewspapers.com.au>
	<4cb25a0e.2a978e0a.7797.33d6@mx.google.com>

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 greg@2ndQuadrant.com 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




view thread (246+ messages)  latest in thread

Message-ID: <4CB3C598.2010302@2ndquadrant.com>
Permalink:  ../4CB3C598.2010302@2ndquadrant.com/
Also on:    postgresql.org/message-id/4CB3C598.2010302@2ndquadrant.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: greg@2ndquadrant.com, eggyknap@gmail.com, craig@postnewspapers.com.au, neil.whelchel@gmail.com
  Subject: Re: Slow count(*) again...
  In-Reply-To: <4CB3C598.2010302@2ndquadrant.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox