Re: Run-time pruning for ModifyTable
От | Amit Langote |
---|---|
Тема | Re: Run-time pruning for ModifyTable |
Дата | |
Msg-id | CA+HiwqE3--u1OaZ+6YEt_R__hXGqccovQe+Y1_8rUMkmObTGTw@mail.gmail.com обсуждение исходный текст |
Ответ на | Run-time pruning for ModifyTable (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
Re: Run-time pruning for ModifyTable
|
Список | pgsql-hackers |
Hi David, On Thu, Jun 27, 2019 at 2:28 PM David Rowley <david.rowley@2ndquadrant.com> wrote: > 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. Thanks for working on this. IIUC, the feature is to skip modifying a given result relation if run-time pruning dictates that none of its existing rows will match some dynamically computable quals. > I think it's mostly okay, > but my brain was overheating a bit at the inheritance_planner changes. I think we need to consider the fact that there is a proposal [1] to get rid of inheritance_planner() as the way of planning UPDATE/DELETEs on inheritance trees. If we go that route, then a given partitioned target table will be expanded at the bottom and so, there's no need for ModifyTable to have its own run-time pruning info, because Append/MergeAppend will have it. Maybe, we will need some code in ExecInitModifyTable() and ExecModifyTable() to handle the case where run-time pruning, during plan tree initialization and plan tree execution respectively, may have rendered modifying a given result relation unnecessary. A cursory look at the patch suggests that most of its changes will be for nothing if [1] materializes. What do you think about that? Thanks, Amit [1] https://www.postgresql.org/message-id/357.1550612935%40sss.pgh.pa.us
В списке pgsql-hackers по дате отправления: