Re: Perfomance bug in v10
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Teodor Sigaev <teodor@sigaev.ru>
Cc: Claudio Freire <klaussfreire@gmail.com>,
David Rowley <david.rowley@2ndquadrant.com>,
Teodor Sigaev <teodor@postgrespro.ru>,
Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2017-06-02T15:02:48Z
Lists: pgsql-hackers
Teodor Sigaev <teodor@sigaev.ru> writes: >> There were old threads about considering a risk factor when estimating >> plans, and I'm thinking this issue is the planner failing to do >> exactly that. > I'm afraid it's tool late for v10 Yeah, we're surely not opening that can of worms for v10. Right now we have to be content with avoiding regressions from 9.6. BTW, was the larger query plan that you showed (with a Materialize node) generated by 9.6, or v10 HEAD? Because I would be surprised if 9.6 did it. But this bug could well cause HEAD to insert Materialize nodes in surprising places, because it would have the effect of making a nestloop with a single row expected from the outer rel look cheaper with a Materialize on the inner rel than without. (Actually I guess 9.6 would have done that too, but only for semi/anti join cases, limiting the visibility of the bug.) regards, tom lane
Commits
-
Fix old corner-case logic error in final_cost_nestloop().
- 23886581b58c 10.0 landed
-
Fix copy/paste mistake in comment
- acbd8375e954 10.0 cited