Re: Sorting Improvements for 8.4 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Sorting Improvements for 8.4
Date
Msg-id 87hcizsa3p.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Sorting Improvements for 8.4  (Simon Riggs <simon@2ndquadrant.com>)
List pgsql-hackers
"Simon Riggs" <simon@2ndquadrant.com> writes:

> The buffer size at max tapes is an optimum - a trade off between
> avoiding intermediate merging and merging efficiently. Freeing more
> memory is definitely going to help in the case of low work_mem and lots
> of runs.

I can't follow these abstract arguments. That's why I tried to spell out a
concrete example.

> I think you're not understanding me.
>
> You only need to record the lowest or highest when a run
> completes/starts. When all runs have been written we then have a table
> of the highest and lowest values for each run. We then scan that to see
> whether we can perform merging in one pass, or if not what kind of
> intermediate merging is required. We keep the merge plan in memory and
> then follow it. So probably very small % of total sort cost, though
> might save you doing intermediate merges with huge costs.

Ok, that's a very different concept than what I was thinking.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Is postgres.gif missing in cvs?
Next
From: Jeff Davis
Date:
Subject: Re: Sorting Improvements for 8.4