On 13 February 2017 at 06:32, Tom Lane <t...@sss.pgh.pa.us> wrote: > It's not so much poor choices as the cost of the optimization attempt --- > if there's a K-relation OR clause, this will increase the cost of planning > by a factor approaching K+1, whether or not you get a better plan out of > it. I ran the regression tests with some instrumentation and determined > that this logic fires a dozen or two times, and fails to produce a plan > that looks cheaper than the standard plan in any of those cases. So if we > go down this road, not only do we need a GUC but I suspect it had better > default to off; only people using star schemas are really likely to get a > win out of it.
I always try to shy away from assuming that the regression test suite is a good reflection of a real world set of queries. It's full of tests for edge cases that are rarely seen in reality. FWIW I did a similar experiment with unique joins and was disappointed to see that it didn't apply in more cases. Yet I've worked with OLTP applications since 2005, and I struggle to recall any many:many joins at all. Perhaps this optimisation is a candidate for only being applied when some sort of planner_strength GUC (as mentioned in FOSDEM developer meeting in 2016) reaches some threshold. There's certainly already some planner smarts that can be skipped when such a GUC is set to a lower level (e.g join removal). We could likely save many cycles if we had the ability to re-plan queries where total_cost > X with more smarts enabled. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
