Re: Run-time pruning for ModifyTable

On Thu, Jan 23, 2020 at 4:31 PM Amit Langote <amitlangote09@gmail.com> wrote:
> Now, the chances of such a big overhaul of how UPDATEs of inheritance
> trees are handled getting into PG 13 seem pretty thin even if I post
> the patch in few days, so perhaps it would make sense to get this
> patch in so that we can give users run-time pruning for UPDATE/DELETE
> in PG 13, provided the code is not very invasive.  If and when the
> aforesaid overhaul takes place, that code would go away along with a
> lot of other code.

Fwiw, I updated the patch, mainly expected/partition_prune.out.  Some
tests in it were failing as a fallout of commits d52eaa09 (pointed out
by Thomas upthread) and 6ef77cf46e8, which are not really related to
the code being changed by the patch.

On the patch itself, it seems straightforward enough.  It simply takes
the feature we have for Append and MergeAppend nodes and adopts it for
ModifyTable which for the purposes of run-time pruning looks very much
like the aforementioned nodes.

Part of the optimizer patch that looks a bit complex is the changes to
inheritance_planner() which is to be expected, because that function
is a complex beast itself.  I have suggestions to modify some comments
around the code added/modified by the patch for clarity; attaching a
delta patch for that.

The executor patch looks pretty benign too.  Diffs that looked a bit
suspicious at first are due to replacing
ModifyTableState.resultRelInfo that is a pointer into
EState.es_result_relations array by an array of ResultRelInfo
pointers, but doing that seems to make the relevant code easier to
follow, especially if you consider the changes that the patch makes to
that code.

I'll set the CF entry to Needs Review, because AFAICS there are no
unaddressed comments.

Thanks,
Amit