Re: Merge algorithms for large numbers of "tapes" - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Merge algorithms for large numbers of "tapes"
Date
Msg-id 17471.1141849929@sss.pgh.pa.us
Whole thread Raw
In response to Re: Merge algorithms for large numbers of "tapes"  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> But do fewer/longer sorted runs translate into not merging back to disk?
> I thought that was controlled by if we had to be able to rewind the
> result set.

A plain SELECT ... ORDER BY doesn't assume that anymore.  It is still
required for some cases such as the input to a merge join, but the
on-the-fly-final-merge code is going to be used a lot more in 8.2 than
it was before.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Ben Chelf
Date:
Subject: Re: Coverity Open Source Defect Scan of PostgreSQL
Next
From: "Dann Corbit"
Date:
Subject: Re: Merge algorithms for large numbers of "tapes"