Re: Run-time pruning for ModifyTable
От | Amit Langote |
---|---|
Тема | Re: Run-time pruning for ModifyTable |
Дата | |
Msg-id | CA+HiwqExqX6mAX2RqqHb5svCmxgq=f8ahN0dXnTv1OnV4ritsA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Run-time pruning for ModifyTable (David Rowley <david.rowley@2ndquadrant.com>) |
Ответы |
RE: Run-time pruning for ModifyTable
|
Список | pgsql-hackers |
On Wed, Jul 3, 2019 at 4:34 PM David Rowley <david.rowley@2ndquadrant.com> wrote: > On Wed, 3 Jul 2019 at 17:27, Amit Langote <amitlangote09@gmail.com> wrote: > > 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? > > Yeah, I had this in mind when writing the patch, but kept going > anyway. I think it's only really a small patch of this patch that > would get wiped out with that change. Just the planner.c stuff. > Everything else is still required, as far as I understand. If I understand the details of [1] correctly, ModifyTable will no longer have N subplans for N result relations as there are today. So, it doesn't make sense for ModifyTable to contain PartitionedRelPruneInfos and for ExecInitModifyTable/ExecModifyTable to have to perform initial and execution-time pruning, respectively. As I said, bottom expansion of target inheritance will mean pruning (both plan-time and run-time) will occur at the bottom too, so the run-time pruning capabilities of nodes that already have it will be used for UPDATE and DELETE too. Thanks, Amit
В списке pgsql-hackers по дате отправления: