Re: Rapidly finding maximal rows

From: bricklen <bricklen(at)gmail(dot)com>
To: James Cranch <jdc41(at)cam(dot)ac(dot)uk>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Rapidly finding maximal rows
Date: 2011-10-11 23:22:06
Message-ID: CAGrpgQ92YCuepxqvJ03kPomooi9MNbEZ4LGE5ycMY06ZSycD3Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Oct 11, 2011 at 3:16 AM, James Cranch <jdc41(at)cam(dot)ac(dot)uk> wrote:

>
> This is EXPLAIN ANALYZEd here:
>  http://explain.depesz.com/s/EiS

"Sort Method: external merge Disk: 35712kB"

>
> SOFTWARE AND HARDWARE
> =====================
>
> I'm running "PostgreSQL 8.4.8 on x86_64-pc-linux-gnu, compiled by GCC
> gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit". It's the standard installation
> from Debian stable (Squeeze), and I haven't messed around with it.
>
> My Linux kernel is 2.6.32-5-amd64.
>
> I have a desktop PC with a Intel Core i7 CPU and 6GB of RAM, and a single
> 640GB Hitachi HDT72106 disk. My root partition is less than 30% full.

Try setting work_mem to something larger, like 40MB to do that sort
step in memory, rather than spilling to disk. The usual caveats apply
though, like if you have many users/queries performing sorts or
aggregations, up to that amount of work_mem may be used at each step
potentially resulting in your system running out of memory/OOM etc.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Claudio Freire 2011-10-12 00:52:16 Re: Composite keys
Previous Message Kevin Grittner 2011-10-11 21:43:00 Re: postgresql query runtime