On 16 May 2018 at 15:10, Tom Lane <t...@sss.pgh.pa.us> wrote: > Simon Riggs <si...@2ndquadrant.com> writes: >> What I would add is that I've seen cases where the extra joins do NOT >> hurt performance, so the extra CPU used to remove the join hurts more >> than the benefit of removing it. Yes, we tried it. > > Interesting. The concern I had was more about the cost imposed on every > query to detect self-joins and try to prove them useless, even in queries > where no benefit ensues. It's possible that we can get that down to the > point where it's negligible; but this says that even the successful-proof > case has to be very cheap.
What I was advocating was an approach that varies according to the query cost, so we don't waste time trying to tune the heck out of OLTP queries, but for larger queries we might take a more considered approach. For advanced optimizations that are costly to check for, skip the check if we are already below a cost threshold. The threshold would be a heuristic that varies according to the cost of the check. I realise that in this case we wouldn't know the full query cost until we've done join planning, so we would need some lower bound estimate to check whether its worth trying to remove joins. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
