Re: fixing consider_parallel for upper planner rels

On Thu, Jun 30, 2016 at 1:13 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> BTW, I just had another thought about reducing the cost of
> has_parallel_hazard checks, to wit: you already made one pass over the
> entire query to verify that there's no PARALLEL UNSAFE functions anywhere.
> If that pass were to also track whether there are any PARALLEL RESTRICTED
> functions anywhere, then in very many common cases, subsequent tests on
> portions of the query would not have to do anything, because we'd already
> know there was nothing to worry about.

Yeah, that's true.  I'm not sure how much those has_parallel_hazard()
checks are costing us.  The ones on quals seem like they are probably
pretty cheap, because if you've got enough quals for the cycles we
spend checking them to matter, it's the proliferation of paths and
RelOptInfos that is going to kill you, not the cost of the
has_parallel_hazard() checks.  I think, anyway.  The ones on target
lists, which I didn't foresee, seem more troubling, because you could
easily be selecting a large number of columns and so we end up with
lots of RelOptInfos that all have long target lists and we've got to
keep checking those target lists over and over again.  I'd like to
find a way to do better there.  I still think that it might be better
to optimize the tlist-is-all-vars case instead of doing what you
propose here, but I'm not sure, and your intuition may well be better
than mine.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company