Re: Merge algorithms for large numbers of "tapes"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
Cc: Luke Lonergan <llonergan(at)greenplum(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Merge algorithms for large numbers of "tapes"
Date: 2006-03-08 20:32:09
Message-ID: 17471.1141849929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Jim C. Nasby" <jnasby(at)pervasive(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dann Corbit 2006-03-08 20:39:55 Re: Merge algorithms for large numbers of "tapes"
Previous Message Luke Lonergan 2006-03-08 18:49:16 Re: Merge algorithms for large numbers of "tapes"