Re: Run-time pruning for ModifyTable

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Run-time pruning for ModifyTable
Дата
Msg-id CA+HiwqGqPdHEtFt_Fe=e+DrCKdRBY9XR9t=uvv_rjG84aYW3Dw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Run-time pruning for ModifyTable  (Amit Langote <amitlangote09@gmail.com>)
Ответы Re: Run-time pruning for ModifyTable
Список pgsql-hackers
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

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: polymorphic table functions light
Следующее
От: Sergiu Velescu
Дата:
Сообщение: RE: New feature proposal (trigger)