Thread: CREATE INDEX ... ONLINE
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. -- greg
Attachment
Still discussion about keyword use.
Your patch has been added to the PostgreSQL unapplied patches list at:
http://momjian.postgresql.org/cgi-bin/pgpatches
It will be applied as soon as one of the PostgreSQL committers reviews
and approves it.
---------------------------------------------------------------------------
Greg Stark wrote:
>
> 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.
>
[ Attachment, skipping... ]
>
>
> --
> greg
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian bruce@momjian.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Greg Stark <gsstark@mit.edu> 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?
regards, tom lane
Tom Lane <tgl@sss.pgh.pa.us> writes: > Greg Stark <gsstark@mit.edu> 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. The only items that remain that I'm aware of are: a) Rename the command and make psql recognize it b) print a message when the wait finishes if we printed one when it started and possibly look into making an option to print the messages even if it doesn't have to wait at all -- currently it only prints the message if it sleeps at least once. I think the patch includes a more than adequate quantity of documentation though I haven't reread it since I wrote it and possibly it may need editing. Also, I don't recall writing any regression tests. But regression tests are kind of a joke here. It would be reasonable to toss one in just to ensure that we don't break non-transactional commands in psql or the grammar, but really no regression test based on a single psql connection is going to be able to test any of the potential bugs we hashed through at the code sprint to get this to work. It won't even be able to reach a big chunk of the code. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com
Greg Stark <gsstark@mit.edu> writes: > > Tom Lane <tgl@sss.pgh.pa.us> writes: > > > Greg Stark <gsstark@mit.edu> 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
Greg Stark <gsstark@mit.edu> writes:
> 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.
We could update them, but if there's really all that much change then
this command is going to suck pretty badly anyway :-(.
Given the current planner behavior (get actual relation length and
multiply by reltuples/relpages to estimate tuple count), the original
reltuples and relpages are probably good enough anyhow. A big change
in index density during phase 2 seems even less likely.
regards, tom lane
Greg Stark <gsstark@mit.edu> 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.
Applied, with ... um ... rather extensive revisions. (I sure hope the
other stuff in the queue is less painful.)
I have done some "retail" testing on this, such as forcing it through
every code path via gdb. But it could definitely do with more testing.
regards, tom lane