Moin, On Tue, October 31, 2017 5:45 pm, Tom Lane wrote: > Pursuant to the discussion at > https://www.postgresql.org/message-id/20171029112420.8920b5f...@mx.zeyos.com > here's a patch to fix the planner so that eval costs and selectivity of > HAVING quals are factored into the appropriate plan node numbers. > Perhaps unsurprisingly, this doesn't change the results of any > existing regression tests. > > It's slightly annoying that this approach will result in calculating > the eval costs and selectivity several times, once for each aggregation > plan type we consider. I thought about inserting RestrictInfo nodes > into the havingQual so that those numbers could be cached, but that turned > out to break various code that doesn't expect to see such nodes there. > I'm not sure it's worth going to the trouble of fixing that; in the big > scheme of things, the redundant calculations likely don't cost much, since > we aren't going to have relevant statistics. > > Comments? If anyone wants to do a real review of this, I'm happy to stick > it into the upcoming CF; but without an expression of interest, I'll just > push it. I don't think there's anything terribly controversial here.
Not a review, but the patch has this: + total_cost += qual_cost.startup + output_tuples * qual_cost.per_tuple; + + output_tuples = clamp_row_est(output_tuples * ... That looks odd to me, it first uses output_tuples in a formula, then overwrites the value with a new value. Should these lines be swapped? Best regards, Tels -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
