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

From Amit Langote
Subject Re: initial pruning in parallel append
Date
Msg-id CA+HiwqFvSp4pzi5OLAw9xf-AvCUdQ5CjxD1uQV8YCbaEV1uzJQ@mail.gmail.com
Whole thread Raw
In response to Re: initial pruning in parallel append  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: initial pruning in parallel append
List pgsql-hackers
On Mon, Aug 7, 2023 at 22:29 Tom Lane <tgl@sss.pgh.pa.us> wrote:
Robert Haas <robertmhaas@gmail.com> writes:
> ... Second, we've generally made a
> decision up until now that we don't want to have a hard dependency on
> stable functions actually being stable. If they aren't, and for
> example you're using index expressions, your queries may return wrong
> answers, but you won't get weird internal error messages, and you
> won't get a crash. I think the bar for this feature is the same.

Yeah, I agree --- wrong answers may be acceptable in such a case, but
crashes or unintelligible error messages aren't.  There are practical
reasons for being tolerant here, notably that it's not that easy
for users to get their volatility markings right.

In the case at hand, I think that means that allowing workers to do
pruning would require hardening the parallel append code against the
situation where their pruning results vary.  Maybe, instead of passing
the pruning results *down*, we could pass them *up* to the leader and
then throw an error if they're different?

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 pruning results for cross-checking, it will have to be from the leader to workers.
--
Thanks, Amit Langote
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Performance degradation on concurrent COPY into a single relation in PG16.
Next
From: "Drouvot, Bertrand"
Date:
Subject: Re: WIP: new system catalog pg_wait_event