On Tue, Sep 5, 2017 at 4:34 AM, Amit Kapila <amit.kapila16@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. :-)
It's used in various places with comments like this:
/* * The path might not return exactly what we want, so fix that. (We * assume that this won't change any
conclusionsabout which was the * cheapest path.) */
And in another place:
* In principle we should re-run set_cheapest() here to identify the * cheapest path, but it seems
unlikelythat adding the same tlist * eval costs to all the paths would change that, so we don't bother.
I think these assumptions were a little shaky even before parallel
query came along, but they're now outright false, because we're not
adding the *same* tlist eval costs to all paths any more. The
parallel paths are getting smaller costs. That probably doesn't
matter much if the expressions in questions are things like a + b, but
when as in Jeff's example it's slow(a), then it matters a lot.
I'd feel a lot happier if Tom were to decide how this ought to be
fixed, because - in spite of some modifications by various parallel
query code - this is basically all his design and mostly his code.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company