On Wed, Aug 9, 2023 at 6:22 AM Amit Langote <amitlangote09@gmail.com> 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.
> >
> > I don't think that's too ugly. I mean you have to have an if statement
> > someplace.
>
> Yes, that makes sense.
>
> It's just that I thought maybe I haven't thought hard enough about
> options before adding a new IsParallelWorker(), because I don't find
> too many instances of IsParallelWorker() in the generic executor code.
> I think that's because most parallel worker-specific logic lives in
> execParallel.c or in Exec*Worker() functions outside that file, so the
> generic code remains parallel query agnostic as much as possible.
Oh, actually, there is an issue here. IsParallelWorker() is not the
right test. Imagine that there's a parallel query which launches some
workers, and one of those calls a user-defined function which again
uses parallelism, launching more workers. This may not be possible
today, I don't really remember, but the test should be "am I a
parallel worker with respect to this plan?" not "am I a parallel
worker at all?".Not quite sure what the best way to code that is. If
we could just test whether we have a ParallelWorkerContext, it would
be easy...
--
Robert Haas
EDB: http://www.enterprisedb.com