Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Tom Lane wrote: >> Yeah, fixed. I had assumed that the existing coding in create_gather_plan >> was OK, because it looked like it was right for a non-projecting node. >> But actually Gather can project (why though?), so it's not right.
> This looks related: > https://www.postgresql.org/message-id/CA%2BTgmoai9Ruhwk61110rY4cNAzoO6npsFEOaEKjM7Zz8i3evHg%40mail.gmail.com Ah, thanks for remembering that thread; I'd forgotten it. Gather is a bit weird, because although it can project (and needs to, per the example of needing to compute a non-parallel-safe function), you would rather push down as much work as possible to the child node; and doing so is semantically OK for parallel-safe functions. (Pushing functions down past a Sort node, for a counterexample, is not so OK if you are concerned about function evaluation order, or even number of executions.) In the current code structure it would perhaps be reasonable to teach apply_projection_to_path about that --- although this would require logic to separate parallel-safe and non-parallel-safe subexpressions, which doesn't quite seem like something apply_projection_to_path should be doing. This seems rather closely related to the discussion around Konstantin Knizhnik's patch to delay function evaluations to after the ORDER BY sort when possible/useful. What I think that patch should be doing is for grouping_planner (or subroutines thereof) to classify tlist items as volatile or expensive or not and generate pre-sort and post-sort targetlists appropriately. That's okay for a top-level feature like ORDER BY, but it doesn't work for Gather which can appear much further down in the plan. So maybe apply_projection_to_path is the only feasible place. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
