Re: Run-time pruning for ModifyTable
От | Amit Langote |
---|---|
Тема | Re: Run-time pruning for ModifyTable |
Дата | |
Msg-id | CA+HiwqHFG4US0Y1m=WQeExBfXAP-PxaWkRObNpxoLMQ3jUxd1A@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Run-time pruning for ModifyTable ("Kato, Sho" <kato-sho@jp.fujitsu.com>) |
Ответы |
RE: Run-time pruning for ModifyTable
|
Список | pgsql-hackers |
Kato-san, On Thu, Jul 4, 2019 at 1:40 PM Kato, Sho <kato-sho@jp.fujitsu.com> wrote: > > 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. > > Does this mean that the generic plan will not have N subplans for N result relations? > I thought [1] would make creating generic plans faster, but is this correct? Yeah, making a generic plan for UPDATE of inheritance tables will certainly become faster, because we will no longer plan the same query N times for N child tables. There will still be N result relations but only one sub-plan to fetch the rows from. Also, planning will still cost O(N), but with a much smaller constant factor. By the way, let's keep any further discussion on this particular topic in the other thread. Thanks, Amit
В списке pgsql-hackers по дате отправления: