To: Josh Berkus <josh@agliodbs.com>
cc: pgsql-bugs@postgresql.org
Subject: Re: Multicolun index creation never completes on 9.0.1/solaris 
In-reply-to: <4D3F86D9.9080200@agliodbs.com> 
References: <4D3F2D10.1020905@agliodbs.com> <21735.1295990515@sss.pgh.pa.us>
	<4D3F86D9.9080200@agliodbs.com>
Comments: In-reply-to Josh Berkus <josh@agliodbs.com>
	message dated "Tue, 25 Jan 2011 18:28:41 -0800"
Date: Tue, 25 Jan 2011 21:49:13 -0500
Message-ID: <14452.1296010153@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Josh Berkus <josh@agliodbs.com> writes:
> LOG:  finished writing run 1 to tape 0: CPU 33.39s/149.02u sec elapsed
> 190.11 sec

> LOG:  finished writing run 2 to tape 1: CPU 62.72s/371.06u sec elapsed
> 443.16 sec

> LOG:  finished writing run 3 to tape 2: CPU 91.04s/599.43u sec elapsed
> 701.37 sec

> LOG:  finished writing run 4 to tape 3: CPU 120.95s/823.59u sec elapsed
> 956.67 sec

> If it's going to take 3 minutes each to write each of 3745 tapes, that
> means completing in around 9 days.

Your logic has nothing to do with what is actually happening.  Could we
have a little bit more patience to see what happens next?

> ... run 2 didn't complete in even 1/2 hour.

That's *good*, not bad.  Long runs mean fewer merge steps.

(Memo to -hackers: what we lack in this trace is any indication of how
long the runs are.  Maybe should add that.  Knuth claims the initial
runs should amount to about 2X maintenance_work_mem on average, but
maybe there's something unusual about the data distribution here.)

			regards, tom lane