Re: generic plans and "initial" pruning
| От | Zhihong Yu |
|---|---|
| Тема | Re: generic plans and "initial" pruning |
| Дата | |
| Msg-id | CALNJ-vSXXROn2BSSs2JDxM74qG5sJ8keZZHcBPXgKt_LXNAe+w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: generic plans and "initial" pruning (Amit Langote <amitlangote09@gmail.com>) |
| Список | pgsql-hackers |
On Fri, May 27, 2022 at 1:10 AM Amit Langote <amitlangote09@gmail.com> wrote:
On Mon, Apr 11, 2022 at 12:53 PM Zhihong Yu <zyu@yugabyte.com> wrote:
> On Sun, Apr 10, 2022 at 8:05 PM Amit Langote <amitlangote09@gmail.com> wrote:
>> Sending v15 that fixes that to keep the cfbot green for now.
>
> Hi,
>
> + /* RT index of the partitione table. */
>
> partitione -> partitioned
Thanks, fixed.
Also, I broke this into patches:
0001 contains the mechanical changes of moving PartitionPruneInfo out
of Append/MergeAppend into a list in PlannedStmt.
0002 is the main patch to "Optimize AcquireExecutorLocks() by locking
only unpruned partitions".
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com
Hi,
In the description:
PartitionPruneResult, made available along with the PlannedStmt by the
I think the second `made available` is redundant (can be omitted).
+ * Initial pruning is performed here if needed (unless it has already been done
+ * by ExecDoInitialPruning()), and in that case only the surviving subplans'
+ * by ExecDoInitialPruning()), and in that case only the surviving subplans'
I wonder if there is a typo above - I don't find ExecDoInitialPruning either in PG codebase or in the patches (except for this in the comment).
I think it should be ExecutorDoInitialPruning.
+ * bit from it just above to prevent empty tail bits resulting in
I searched in the code base but didn't find mentioning of `empty tail bit`. Do you mind explaining a bit about it ?
Cheers
В списке pgsql-hackers по дате отправления: