Run-time pruning for ModifyTable

Поиск
Список
Период
Сортировка
От David Rowley
Тема Run-time pruning for ModifyTable
Дата
Msg-id CAKJS1f9R-2_D7jARRgEOC72=Y9ytLzk_FTeR0pTEMFJQy8gO+g@mail.gmail.com
обсуждение исходный текст
Ответы Re: Run-time pruning for ModifyTable  (Amit Langote <amitlangote09@gmail.com>)
Re: Run-time pruning for ModifyTable  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
Deja vu from this time last year when despite everyone's best efforts
(mostly Alvaro) we missed getting run-time pruning in for MergeAppend
into the PG11 release.   This year it was ModifyTable, which is now
possible thanks to Amit and Tom's modifications to the inheritance
planner.

I've attached what I have so far for this.  I think it's mostly okay,
but my brain was overheating a bit at the inheritance_planner changes.
I'm not entirely certain that what I've got is correct there. My brain
struggled a bit with the code that Tom wrote to share the data
structures from the SELECT invocation of the grouping_planner() in
inheritance_planner() regarding subquery RTEs. I had to pull out some
more structures from the other PlannerInfo structure in order to get
the base quals from the target rel. I don't quite see a reason why
it's particularly wrong to tag those onto the final_rel, but I'll
prepare myself to be told that I'm wrong about that.

I'm not particularly happy about having to have written the
IS_DUMMY_MODIFYTABLE macro. I just didn't see a more simple way to
determine if the ModifyTable just contains a single dummy Append path.

I also had to change the ModifyTable resultRelInfo pointer to an array
of pointers. This seems to be required since we need to somehow ignore
ResultRelInfos which were pruned.  I didn't do any performance testing
for the added level of indirection, I just imagined that it's
unmeasurable.

I'll include this in for July 'fest.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

Вложения

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: mcvstats serialization code is still shy of a load
Следующее
От: Pavan Deolasee
Дата:
Сообщение: Re: COPY FREEZE and setting PD_ALL_VISIBLE/visibility map bits