On Thu, 6 Feb 2020 at 11:12, Adam Brusselback <adambrusselback@xxxxxxxxx> wrote: > > > You can create a library of > > reusable views that are small, easy-to-understand and readable. Then > > you build them up into bigger views, and finally query from them. But > > then you end up with lots of (hidden) self-joins. > > I will concur with this use case being pretty common, but also something I > have actively avoided anywhere performance is important because of the > lack of this optimization. > > Even still, I have 20+ views like that in my database. I think the best direction to move in to push that forward would be to go and benchmark the proposed patch and see if the overhead of detecting the self joined relations is measurable with various queries with varying numbers of joins. It does not sound too like it would be a great deal of effort to look through the rangetable for duplicate Oids and only do further processing to attempt self-join removal if there are. However, if that effort happened to slow down all queries by say 5%, then perhaps it would be a bad idea. People's opinions don't really have much traction for arguments on this. Unbiased and reproducible benchmarks should be used as evidence to support discussion. Doing worst-case and average-case benchmarks initially will save you time, as someone will almost certainly ask if you don't do it. (I've not been following the thread for the patch) -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
