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 OAA54560
	for <pgsql-sql@hub.org>; Mon, 11 Oct 1999 14:46:33 -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 OAA08561;
	Mon, 11 Oct 1999 14:45:18 -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 12:14:28 -0400 (EDT)
	<199910111614.MAA03460@candle.pha.pa.us>
Date: Mon, 11 Oct 1999 14:45:18 -0400
Message-ID: <8559.939667518@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Bruce Momjian <maillist@candle.pha.pa.us> writes:
> Wonder how our create index does it.  Seems it is must be similar.

CREATE INDEX (for btrees) is very similar, and really ought to share
code.  Someone apparently didn't want to figure out how to generalize
psort.c to handle index tuples, though.  The CREATE INDEX code is a
little better for large amounts of data but a lot worse for small
amounts --- AFAICT it doesn't take any shortcuts, even when everything
fits in memory.  (I'm sure you've noticed that CREATE INDEX hits the
disk pretty hard even when the source table is empty :-(.)

I'm planning to merge the two sets of code and keep the best features of
both.  I already have some first-draft code that allows them to work
with >2gig data sets.

			regards, tom lane