Horton

Re: tuplesort memory usage: grow_memtuples

Peter Geoghegan <peter@2ndquadrant.com>

View thread
From: Peter Geoghegan <peter@2ndquadrant.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-07-25T21:51:50Z
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. Incorporate a couple of recent tuplesort.c improvements into tuplestore.c.

On 3 March 2012 20:22, Jeff Janes <jeff.janes@gmail.com> wrote:
> Add it all up, and instead of pre-reading 32 consecutive 8K blocks, it
> pre-reads only about 1 or 2 consecutive ones on the final merge.  Now
> some of those could be salvaged by the kernel keeping track of
> multiple interleaved read ahead opportunities, but in my hands vmstat
> shows a lot of IO wait and shows reads that seem to be closer to
> random IO than large read-ahead.  If it used truly efficient read
> ahead, CPU would probably be limiting.

Can you suggest a benchmark that will usefully exercise this patch?

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services