On Wed, Aug 9, 2023 at 8:57 AM Amit Langote wrote:
> I checked enough to be sure that IsParallelWorker() is reliable at the
> time of ExecutorStart() / ExecInitNode() in ParallelQueryMain() in a
> worker. However, ParallelWorkerContext is not available at that
> point. Here's the relevant part
On Wed, Aug 9, 2023 at 9:48 PM Robert Haas wrote:
> On Wed, Aug 9, 2023 at 6:22 AM Amit Langote wrote:
> > > > I'm assuming it's not
> > > > too ugly if ExecInitAppend() uses IsParallelWorker() to decide whether
> > > > it should be writing to EState.es_part_prune_results or reading from
> > > >
On Wed, Aug 9, 2023 at 6:22 AM Amit Langote wrote:
> > > I'm assuming it's not
> > > too ugly if ExecInitAppend() uses IsParallelWorker() to decide whether
> > > it should be writing to EState.es_part_prune_results or reading from
> > > it -- the former if in the leader and the latter in a worker.
On Tue, Aug 8, 2023 at 11:16 PM Robert Haas wrote:
> On Tue, Aug 8, 2023 at 2:58 AM Amit Langote wrote:
> > Or we could consider something like the patch I mentioned in my 1st
> > email. The idea there was to pass the pruning result via a separate
> > channel, not the DSM chunk linked into the P
On Tue, Aug 8, 2023 at 2:58 AM Amit Langote wrote:
> > 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?
>
> MergeAppend can't be parallel-aware atm, so o
On Tue, Aug 8, 2023 at 12:53 AM Robert Haas wrote:
> On Mon, Aug 7, 2023 at 10:25 AM Amit Langote 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 thei
On Mon, Aug 7, 2023 at 10:25 AM Amit Langote 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 pr
On Mon, Aug 7, 2023 at 22:29 Tom Lane wrote:
> Robert Haas 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
Robert Haas 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 we
On Tue, Jun 27, 2023 at 9:23 AM Amit Langote wrote:
> Maybe that stuff could be resurrected, though I was wondering if the
> risk of the same initial pruning steps returning different results
> when performed repeatedly in *one query lifetime* aren't pretty
> minimal or maybe rather non-existent?
Hi,
In an off-list chat, Robert suggested that it might be a good idea to
look more closely into $subject, especially in the context of the
project of moving the locking of child tables / partitions to the
ExecInitNode() phase when executing cached generic plans [1].
Robert's point is that a work
11 matches
Mail list logo
