Re: PostgreSQL underestimates sorting

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Markus Schaber" <schabi(at)logix-tt(dot)com>
Cc: "PostgreSQL Performance List" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PostgreSQL underestimates sorting
Date: 2006-11-23 15:20:35
Message-ID: 1164295236.3841.629.camel@silverbirch.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 2006-11-22 at 11:17 +0100, Markus Schaber wrote:

> PostgreSQL 8.1 (and, back then, 7.4) have the tendency to underestimate
> the costs of sort operations, compared to index scans.
>
> The Backend allocates gigs of memory (we've set sort_mem to 1 gig), and
> then starts spilling out more Gigs of temporary data to the disk. So the
> execution gets - in the end - much slower compared to an index scan, and
> wastes lots of disk space.
>
> We did not manage to tune the config values appropriately, at least not
> without causing other query plans to suffer badly.

8.2 has substantial changes to sort code, so you may want to give the
beta version a try to check for how much better it works. That's another
way of saying that sort in 8.1 and before has some performance problems
when you are sorting more than 6 * 2 * work_mem (on randomly sorted
data) and the cost model doesn't get this right, as you observe.

Try enabling trace_sort (available in both 8.1 and 8.2) and post the
results here please, which would be very useful to have results on such
a large real-world sort.

--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2006-11-23 16:41:36 Re: [PERFORM] Direct I/O issues
Previous Message Arjen van der Meijden 2006-11-23 08:40:43 Re: availability of SATA vendors