On Thu, Sep 17, 2015 at 6:58 AM, Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Sep 3, 2015 at 6:21 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > > [ new patches ] > > + pscan = shm_toc_lookup(node->ss.ps.toc, PARALLEL_KEY_SCAN); > > This is total nonsense. You can't hard-code the key that's used for > the scan, because we need to be able to support more than one parallel > operator beneath the same funnel. For example: > > Append > -> Partial Seq Scan > -> Partial Seq Scan >
Okay, but I think the same can be achieved with this as well. Basic idea
is that each worker will work on one planned statement at a time and in
above case there will be two different planned statements and they will
store partial seq scan related information in two different loctions in
toc, although the key (PARALLEL_KEY_SCAN) would be same and I think this
will quite similar to what we are already doing for response queues.
The worker will work on one of those keys based on planned statement
which it chooses to execute. I have explained this in somewhat more details
in one of my previous mails [1].
> Each partial sequential scan needs to have a *separate* key, which > will need to be stored in either the Plan or the PlanState or both > (not sure exactly). Each partial seq scan needs to get assigned a > unique key there in the master, probably starting from 0 or 100 or > something and counting up, and then this code needs to extract that > value and use it to look up the correct data for that scan. >
In that case also, multiple workers can worker on same key, assuming
in your above example, multiple workers will be required to execute
each partial seq scan. In this case we might need to see how to map
instrumentation information for a particular execution.