Re: Parallel Seq Scan

On Fri, Oct 23, 2015 at 5:45 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Oct 23, 2015 at 3:35 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
wrote:
> > Considering parallelism at RelOptInfo level in the way as done in patch,
> > won't consider the RelOptInfo's for child relations in case of Append
node.
> > Refer build_simple_rel().
>
> Hmm, true, but what can go wrong there? The same quals apply to both,
> and either both are temp or neither is.
>

The base rel's consider_parallel flag won't be percolated to childrels, so
even
if we mark base rel as parallel capable, while generating the path it won't
be considered. I think we need to find a way to pass on that information if
we want to follow this way.

>
> >> The advantage of this is that the logic is centralized. If we have
> >> parallel seq scan and also, say, parallel bitmap heap scan, your
> >> approach would require that we duplicate the logic to check for
> >> parallel-restricted functions for each path generation function.
> >
> > Don't we anyway need that irrespective of caching it in RelOptInfo?
> > During bitmappath creation, bitmapqual could contain something
> > which needs to be evaluated for parallel-safety as it is built based
> > on index paths which inturn can be based on some join clause. As per
> > patch, the join clause parallel-safety is checked much later than
> > generation bitmappath.
>
> Yes, it's possible there could be some additional checks needed here
> for parameterized paths. But we're not quite there yet, so I think we
> can solve that problem when we get there. I have it in mind that in
> the future we may want a parallel_safe flag on each path, which would
> normally match the consider_parallel flag on the RelOptInfo but could
> instead be false if the path internally uses parallelism (since,
> currently, Gather nodes cannot be nested) or if it's got
> parallel-restricted parameterized quals. However, that seems like
> future work.
>

True, we can do that way. What I was trying to convey by above is
that we anyway need checks during path creation atleast in some
of the cases, so why not do all the checks at that time only as I
think all the information will be available at that time.

I think if we store parallelism related info in RelOptInfo, that can also
be made to work, but the only worry I have with that approach is we
need to have checks at two levels one at RelOptInfo formation time
and other at Path formation time.

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com