On Fri, Jan 14, 2022 at 2:25 PM James Coleman <jtc...@gmail.com> wrote: > I've been chewing on this a bit, and I was about to go re-read the > code and see how easy it'd be to do exactly what you're suggesting in > generate_gather_paths() (and verifying it doesn't need to happen in > other places). However there's one (I think large) gotcha with that > approach (assuming it otherwise makes sense): it means we do > unnecessary work. In the current patch series we only need to recheck > parallel safety if we're in a situation where we might actually > benefit from doing that work (namely when we have a correlated > subquery we might otherwise be able to execute in a parallel plan). If > we don't track that status we'd have to recheck the full parallel > safety of the path for all paths -- even without correlated > subqueries.
I don't think there's an intrinsic problem with the idea of making a tentative determination about parallel safety and then refining it later, but I'm not sure why you think it would be a lot of work to figure this out at the point where we generate gather paths. I think it's just a matter of testing whether the set of parameters that the path needs as input is the empty set. It may be that neither extParam nor allParam are precisely that thing, but I think both are very close, and it seems to me that there's no theoretical reason why we can't know for every path the set of inputs that it requires "from the outside." -- Robert Haas EDB: http://www.enterprisedb.com