On Mon, Aug 7, 2023 at 22:29 Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@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
