Re: generic plans and "initial" pruning - Mailing list pgsql-hackers

From Zhihong Yu
Subject Re: generic plans and "initial" pruning
Date
Msg-id CALNJ-vSXXROn2BSSs2JDxM74qG5sJ8keZZHcBPXgKt_LXNAe+w@mail.gmail.com
Whole thread Raw
In response to Re: generic plans and "initial" pruning  (Amit Langote <amitlangote09@gmail.com>)
List 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:

is made available to the actual execution via
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'

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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: "ERROR: latch already owned" on gharial
Next
From: Tom Lane
Date:
Subject: Re: "ERROR: latch already owned" on gharial