On Wed, Sep 6, 2017 at 1:47 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >>> Okay, now I understand your point, but I think we already change the >>> cost of paths in apply_projection_to_path which is done after add_path >>> for top level scan/join paths. > >> Yeah. I think that's a nasty hack, and I think it's Tom's fault. :-) > > Yeah, and it's also documented: > > * This has the same net effect as create_projection_path(), except that if > * a separate Result plan node isn't needed, we just replace the given path's > * pathtarget with the desired one. This must be used only when the caller > * knows that the given path isn't referenced elsewhere and so can be modified > * in-place. > > If somebody's applying apply_projection_to_path to a path that's already > been add_path'd, that's a violation of the documented restriction.
/me is confused. Isn't that exactly what grouping_planner() is doing, and has done ever since your original pathification commit (3fc6e2d7f5b652b417fa6937c34de2438d60fa9f)? It's iterating over current_rel->pathlist, so surely everything in there has been add_path()'d. -- 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
