On Wed, Aug 9, 2023 at 6:22 AM Amit Langote <amitlangot...@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
