On Thu, Jul 18, 2019 at 12:02:32PM +0900, Michael Paquier wrote:
> There are a couple of approaches that we could do to fix that. The
> first one I could think about is to change the relcache level so as we
> don't apply planner-level optimizations when creating a concurrent
> index entry. Another one, which is less invasive, is to just update
> the list of expressions and predicates after calling
> BuildIndexInfo(). Still that means overriding the contents of the
> relcache with what has been optimized for the planner to what we want
> to use for the reindex build and I think that this weakens the logic
> of index_build.
I have done some work on that, and for now I am finishing with the
attached. This takes the approach of updating BuildIndexInfo() so as
the optimizations for the planner are not done.
That's not completely right yet though as even if it passes your
initial test case, this does not allow the index expressions and
predicates to have an exact match. I have designed a test case for
this purpose which stores the contents of pg_node_tree before and
after the REINDEX and even if the collation gets right, all the
location fields from pg_node_tree get reset. The solution is not
complete, still the test case is quite useful. So even if the
solution happens to not be like the attached, I'd rather keep the
test case and perhaps extend it.
--
Michael