Re: Poor plan when joining against a union containing a join - Mailing list pgsql-performance

From David Leverton
Subject Re: Poor plan when joining against a union containing a join
Date
Msg-id CALc3eMW1zc11RJa+grayreoJ8Wz6gYwfSNM7UWeqaWUe7bS4cg@mail.gmail.com
Whole thread Raw
In response to Re: Poor plan when joining against a union containing a join  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On 7 March 2013 18:47, Tom Lane <tgl@sss.pgh.pa.us> 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@sss.pgh.pa.us> 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.


pgsql-performance by date:

Previous
From: "Emre Hasegeli"
Date:
Subject: PostgreSQL 9.2.3 performance problem caused Exclusive locks
Next
From: "Emre Hasegeli"
Date:
Subject: Re: PostgreSQL 9.2.3 performance problem caused Exclusive locks