X-Original-To: pgsql-patches-postgresql.org@postgresql.org Received: from localhost (wm.hub.org [200.46.204.128]) by postgresql.org (Postfix) with ESMTP id 2565E9FB275 for ; Thu, 17 Aug 2006 08:47:37 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.128]) (amavisd-new, port 10024) with ESMTP id 24335-09 for ; Thu, 17 Aug 2006 11:47:30 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey- Received: from stark.xeocode.com (stark.xeocode.com [216.58.44.227]) by postgresql.org (Postfix) with ESMTP id A49EE9FA5FC for ; Thu, 17 Aug 2006 08:47:30 -0300 (ADT) Received: from localhost ([127.0.0.1] helo=stark.xeocode.com) by stark.xeocode.com with smtp (Exim 3.36 #1 (Debian)) id 1GDgLE-00042m-00; Thu, 17 Aug 2006 07:47:16 -0400 To: Tom Lane Cc: Greg Stark , pgsql-patches@postgresql.org Subject: Re: CREATE INDEX ... ONLINE References: <87ejwpifeu.fsf@stark.xeocode.com> <20246.1155741466@sss.pgh.pa.us> In-Reply-To: <20246.1155741466@sss.pgh.pa.us> From: Greg Stark Organization: The Emacs Conspiracy; member since 1992 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 Date: 17 Aug 2006 07:47:15 -0400 Message-ID: <873bbvy470.fsf@stark.xeocode.com> Lines: 27 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=1.384 tagged_above=0 required=5 tests=SPF_SOFTFAIL X-Spam-Level: * X-Archive-Number: 200608/230 X-Sequence-Number: 20746 Greg Stark writes: > > Tom Lane writes: > > > Greg Stark writes: > > > Updated patch. Fixed a few minor things, added documentation and regression > > > tests. Unfortunately I can't test the regression tests because I get a > > > segmentation fault earlier in the same file due to a GIN index build. So I > > > haven't updated the "expected" output. > > > > What's the status of this patch --- have you done anything more with it > > since the 13-Jul submission? > > I haven't done anything. I was mostly waiting until I got some feedback about > the code quality. I figured if there were parts that had to be reworked or > fixed up I would prefer to do that first before worrying about perfecting > details which is all that I believe remain. Just remembered one open question I had. I'm not clear what to do with the index statistics. It may be that the current code is basically the right thing -- it leaves the statistics as they are after phase 1, ie after the regular index build before we go through looking for newly added tuples. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com