On 12 February 2017 at 13:30, Tom Lane <t...@sss.pgh.pa.us> wrote: > I wrote a POC patch for this on a long airplane ride. It's not complete, > and I'm sure there are bugs as well, but it makes your example case > better. What I did about the de-duplication issue is to de-dup using > the CTIDs of all baserels in the query. This means the optimization > is only applicable to cases where all the rels have CTIDs ... but other > methods such as inspecting unique keys ain't gonna work for non-table > rels either, so I think this is about the best we can hope for. > However, I did not understand your point about:
This is very interesting. Couldn't this be even more generic and instead of looking at just the jointree quals, also look at the join conditions too, as I think you can use this to also transforms queries such as: select * from t1 inner join t2 on t1.a = t2.a or t1.b = t2.b; I imagine you'd also want an enable_unionor GUC which can be used to disable this for when the planner makes a poor choice. -- 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