On Wed, Mar 9, 2016 at 12:33 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > 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.
I think for v1 it would be fine to make this all-or-nothing; that's what I had in mind to do. That is, if the entire tlist is parallel-safe, push it all down. If not, let the workers just return the necessary Vars and have Gather compute the final tlist. Now, obviously one could do better. If the tlist contains several expensive functions that are parallel-safe and one inexpensive function that isn't, you'd obviously prefer to compute the parallel-safe stuff in the workers and just compute the one inexpensive thing in the leader. But that's significantly more complicated and I'm not sure it's worth spending a lot of time getting it right just now. Not that I'm complaining if you feel the urge. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
