Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 384F8133655C for ; Tue, 25 Jan 2011 23:10:09 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 64022-03 for ; Wed, 26 Jan 2011 03:10:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id 2F246133616B for ; Tue, 25 Jan 2011 23:10:01 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id p0Q39qCC014812; Tue, 25 Jan 2011 22:09:52 -0500 (EST) To: Josh Berkus cc: pgsql-bugs@postgresql.org Subject: Re: Multicolun index creation never completes on 9.0.1/solaris In-reply-to: <4D3F8D7F.6020806@agliodbs.com> References: <4D3F2D10.1020905@agliodbs.com> <21735.1295990515@sss.pgh.pa.us> <4D3F86D9.9080200@agliodbs.com> <14452.1296010153@sss.pgh.pa.us> <4D3F8D7F.6020806@agliodbs.com> Comments: In-reply-to Josh Berkus message dated "Tue, 25 Jan 2011 18:57:03 -0800" Date: Tue, 25 Jan 2011 22:09:52 -0500 Message-ID: <14811.1296011392@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201101/206 X-Sequence-Number: 29228 Josh Berkus writes: > 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. That would result in a very long initial run (probably all or most of the data), which fits with your observation so far. But we don't know what happens after that. BTW, are you paying attention to vmstat or similar measure of the amount of I/O and CPU work getting done? vmstat data ought to make it possible to estimate the size of those runs, even though the trace_sort logic isn't telling us. regards, tom lane