Re: Reducing relation locking overhead

Hannu Krosing <hannu(at)skype(dot)net> writes:
> How do you plan to determine "any rows not already present in the index"
> without explicitly remembering the start and end snapshots of existing
> CREATE INDEX (SNAP1 and SNAP2 in my proposal)?

I was thinking in terms of actually looking into the index to see if the
particular TID is present or not. You could use snapshots to optimize
this by avoiding index probes for tuples that must be present, which
hopefully will be most of 'em. Also you need a snapshot to detect
tuples that are new enough that they certainly will be indexed by their
inserting transaction, so that you don't have a race condition between
an active inserter and the REINDEX. (I think this is possible but maybe
I missed something.) That leaves you looking at just the tuples
inserted by transactions that might or might not have known about the
index. So yeah, you do need SNAP1 and SNAP2 but they're being used in
a different way than the original proposal.

> In the last round of discussion you pointed out that index itself can't
> be effectively used for this in case there are lots of equal index keys.

True, but if you can avoid going to the index at all for the majority of
the tuples, I think this is tolerable. In any case the design idea here
seems to be "we don't care how long REINDEX takes as long as it's not
blocking anyone".

regards, tom lane