Received: from sss.sss.pgh.pa.us (sss.pgh.pa.us [209.114.166.2])
	by hub.org (8.9.3/8.9.3) with ESMTP id LAA22031
	for <pgsql-sql@hub.org>; Mon, 11 Oct 1999 11:45:59 -0400 (EDT)
	(envelope-from tgl@sss.pgh.pa.us)
Received: from sss.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.sss.pgh.pa.us (8.9.1/8.9.1) with ESMTP id LAA08119;
	Mon, 11 Oct 1999 11:45:14 -0400 (EDT)
To: Bruce Momjian <maillist@candle.pha.pa.us>
cc: "Steven M. Wheeler" <swheeler@sabre.com>, pgsql-sql@hub.org
Subject: Re: [SQL] Questions about vacuum analyze 
In-reply-to: Your message of Mon, 11 Oct 1999 11:07:44 -0400 (EDT)
	<199910111507.LAA29115@candle.pha.pa.us>
Date: Mon, 11 Oct 1999 11:45:13 -0400
Message-ID: <8117.939656713@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> The thing I liked about the existing algorithm is that it did the
> sorting without the page faulting/thrashing caused by many sort
> algorithms.

Yes, I think we want to stick with the basic architecture of an
initial replacement-selection filter operating in limited memory,
followed by merge passes.  I'm just thinking about how to reduce
the amount of disk space chewed up by intermediate merge results...

			regards, tom lane