Re: initial pruning in parallel append

On Mon, Aug 7, 2023 at 22:29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Robert Haas <robertmhaas(at)gmail(dot)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