On Sat, Jun 4, 2016 at 4:21 PM, Kevin Grittner <kgrittn@gmail.com> wrote:
> On Fri, Jun 3, 2016 at 4:24 PM, Kevin Grittner <kgrittn@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