Received: from candle.pha.pa.us (root@s5-03.ppp.op.net [209.152.195.67]) by hub.org (8.9.3/8.9.3) with ESMTP id MAA28840 for ; Mon, 11 Oct 1999 12:33:08 -0400 (EDT) (envelope-from maillist@candle.pha.pa.us) Received: (from maillist@localhost) by candle.pha.pa.us (8.9.0/8.9.0) id MAA03460; Mon, 11 Oct 1999 12:14:28 -0400 (EDT) From: Bruce Momjian Message-Id: <199910111614.MAA03460@candle.pha.pa.us> Subject: Re: [SQL] Questions about vacuum analyze In-Reply-To: <8117.939656713@sss.pgh.pa.us> from Tom Lane at "Oct 11, 1999 11:45:13 am" To: Tom Lane Date: Mon, 11 Oct 1999 12:14:28 -0400 (EDT) CC: "Steven M. Wheeler" , pgsql-sql@hub.org X-Mailer: ELM [version 2.4ME+ PL56 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit > Bruce Momjian 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... Wonder how our create index does it. Seems it is must be similar. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026