On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner <kgri...@gmail.com> wrote: > On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner <kgri...@gmail.com> wrote: >> Consequently, causing the index to be ignored in planning when >> using the old index > > That last line should have read "using an old snapshot" > >> is not a nice optimization, but necessary for >> correctness. We already have logic to do this for other cases >> (like HOT updates), so it is a matter of tying in to that existing >> code correctly. This won't be all that novel. > > Just to demonstrate that, the minimal patch to fix behavior in this > area would be: > > diff --git a/src/backend/catalog/index.c b/src/backend/catalog/index.c > index 31a1438..6c379da 100644 > --- a/src/backend/catalog/index.c > +++ b/src/backend/catalog/index.c > @@ -2268,6 +2268,9 @@ IndexBuildHeapRangeScan(Relation heapRelation, > Assert(numblocks == InvalidBlockNumber); > } > > + if (old_snapshot_threshold >= 0) > + indexInfo->ii_BrokenHotChain = true; > + > reltuples = 0; > > /* > > Of course, ii_BrokenHotChain should be renamed to something like > ii_UnsafeForOldSnapshots, and some comments need to be updated; but > the above is the substance of it.
I don't know why we'd want to rename it like that... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers