Skip site navigation (1) Skip section navigation (2)

Re: join removal

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Stark <stark(at)mit(dot)edu>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: join removal
Date: 2010-03-28 17:23:11
Message-ID: 23400.1269796991@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> I'm alarmed by your follow-on statement that the current code can't
>> handle the two-levels of removable join case.  Seems like it ought to
>> form {B C} as a path over {B} and then {A B C} as a path over {A}.

> Actually I think it ought to form {A B} as a no-op join and then be able
> to join {A B} to {C} as a no-op join.  It won't recognize joining A to
> {B C} as a no-op because the RHS isn't a baserel.  But yeah, I was quite
> surprised at the failure too.  We should take the time to understand why
> it's failing before we go further.

OK, I traced through it, and the reason HEAD fails on this example is
that it *doesn't* recognize {A B} as a feasible no-op join, for
precisely the reason that it sees some B vars marked as being needed for
the not-yet-done {B C} join.  So that path is blocked, and the other
possible path to the desired result is also blocked because it won't
consider {B C} as a valid RHS for a removable join.

I don't see any practical way to escape the false-attr_needed problem
given the current code structure.  We could maybe hack our way to a
solution by weakening the restriction against the RHS being a join,
eg by noting that the best path for the RHS is a no-op join and then
drilling down to the one baserel.  But it seems pretty ugly.

So I think the conclusion is clear: we should consign the current
join-removal code to the dustbin and pursue the preprocessing way
instead.  Will work on it today.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2010-03-28 18:04:05
Subject: Re: join removal
Previous:From: Tom LaneDate: 2010-03-28 16:47:02
Subject: Re: More idle thoughts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group