Re: initial pruning in parallel append - Mailing list pgsql-hackers

From Robert Haas
Subject Re: initial pruning in parallel append
Date
Msg-id CA+TgmoZhKHGop5qeFT1CMqvYYiqPG2ymnZKguZN18K+H_DvB7g@mail.gmail.com
Whole thread Raw
In response to Re: initial pruning in parallel append  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: initial pruning in parallel append
List pgsql-hackers
On Mon, Aug 7, 2023 at 10:25 AM Amit Langote <amitlangote09@gmail.com> wrote:
> Note we’re talking here about “initial” pruning that occurs during ExecInitNode(). Workers are only launched during
ExecGather[Merge]()which thereafter do ExecInitNode() on their copy of the the plan tree.  So if we are to pass the
pruningresults for cross-checking, it will have to be from the leader to workers. 

That doesn't seem like a big problem because there aren't many node
types that do pruning, right? I think we're just talking about Append
and MergeAppend, or something like that, right? You just need the
ExecWhateverEstimate function to budget some DSM space to store the
information, which can basically just be a bitmap over the set of
child plans, and the ExecWhateverInitializeDSM copies the information
into that DSM space, and ExecWhateverInitializeWorker() copies the
information from the shared space back into the local node (or maybe
just points to it, if the representation is sufficiently compatible).
I feel like this is an hour or two's worth of coding, unless I'm
missing something, and WAY easier than trying to reason about what
happens if expression evaluation isn't as stable as we'd like it to
be.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: generic plans and "initial" pruning
Next
From: Robert Haas
Date:
Subject: Re: generic plans and "initial" pruning