On Thu, Jun 30, 2016 at 1:13 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers