Message-ID: <4D3F8D7F.6020806@agliodbs.com>
Date: Tue, 25 Jan 2011 18:57:03 -0800
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
	rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: pgsql-bugs@postgresql.org
Subject: Re: Multicolun index creation never completes on 9.0.1/solaris
References: <4D3F2D10.1020905@agliodbs.com> <21735.1295990515@sss.pgh.pa.us>
	<4D3F86D9.9080200@agliodbs.com> <14452.1296010153@sss.pgh.pa.us>
In-Reply-To: <14452.1296010153@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


>> 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?

OK, I'll let it run overnight and give you the trace output.


> (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.)

Well, for the straight test on event_time, the rows in the table should
have been more-or-less physically already in order.  This table is
most-insert, and event_time mostly corresponds to current server time.

For the composite index, rows would be more randomly distributed.

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com