On 7 March 2013 18:47, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Good idea, but no such luck in that form: it's still not going to try to > push the parameterization down into the sub-query. I think you'd have > to write out the query with the views expanded and manually put the > WHERE restrictions into the lowest join level. [ experiments... ] > Looks like only the UNION view has to be manually expanded to get a > good plan with HEAD: Thanks for checking that, good to know that there's a way forward with 9.3 even in the worst case of not finding anything for 9.2. > You might be able to accomplish something similar without LATERAL, if > you're willing to give up the notational convenience of the views. > Don't have time right now to experiment further though. No problem, I don't expect you do to everything for me ;-) (although if you do find the time to come up with something before I do, that would of course be very welcome) and there's no desperate rush in any case. Pondering your earlier comment some more: On 7 March 2013 05:52, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > I believe the core issue here (as of 9.2) is > that we're not willing to generate parameterized paths for subquery > relations. We could do that without a huge amount of new code, > I think, but the scary thing is how much time it might take to generate > (and then discard most of the) plans for assorted parameterizations of > complicated subqueries. Would it be reasonable to support this with some sort of configurable complexity threshold for the subquery, above which the planner won't bother? Probably not the most elegant solution, but maybe something to consider. It seems similar in spirit to from_collapse_limit and join_collapse_limit, in the sense of controlling how much effort to put in for complex queries. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
