Re: [sqlsmith] Failed to generate plan on lateral subqueries

From: David Fetter <david(at)fetter(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andreas Seltenreich <seltenreich(at)gmx(dot)de>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [sqlsmith] Failed to generate plan on lateral subqueries
Date: 2015-12-09 14:58:52
Views: Raw Message | Whole Thread | Download mbox
Lists: pgsql-hackers

On Tue, Dec 08, 2015 at 12:13:41PM -0500, Tom Lane wrote:
> Andreas Seltenreich <seltenreich(at)gmx(dot)de> writes:
> >> I no longer see "failed to build any n-way joins" after pulling,
> >> but there are still instances of "could not devise a query plan".
> >> Samples below.
> > sorry, I spoke too soon: nine of the former have been logged
> > through the night. I'm attaching a larger set of sample queries
> > this time in case that there are still multiple causes for the
> > observed errors.
> Hm. At least in the first of these cases, the problem is that the
> code I committed yesterday doesn't account for indirect lateral
> dependencies. That is, if S1 depends on S2 which depends on the
> inner side of an outer join, it now knows not to join S2 directly to
> the outer side of the outer join, but it doesn't realize that the
> same must apply to S1.
> Maybe we should redefine lateral_relids as the transitive closure of
> a rel's lateral dependencies? Not sure.

That seems like it would fix the problem once and for good. Is there
any reason to believe that the lateral dependencies could go in a
loop, i.e. is there a reason to put in checks for same in the
transitive closure construction?

David Fetter <david(at)fetter(dot)org>
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com

Remember to vote!
Consider donating to Postgres:

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2015-12-09 15:29:20 Re: Support for N synchronous standby servers - take 2
Previous Message Noah Misch 2015-12-09 14:43:19 Re: Rework the way multixact truncations work