On Thu, 2008-06-26 at 13:42 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > We can check for removal of a rel by
>
> > 1. inspecting the target list for the query to see if there are rels
> > that do not provide any attributes. (We might also use equivalence
> > classes to recode the targetlist to minimise the numbers of tables
> > touched, but I think that might be overkill).
>
> More to the point, it would be wrong. Equivalence classes do not imply
> that two values considered equivalent are equal for all purposes, and
> since we don't know what the client is going to do with the returned
> data, we can't substitute some other value for the one requested.
>
> > So some thoughts on where to attempt this would be very useful.
>
> The hard part of this is figuring out where to do the work. As you say,
> doing it during prepjointree seems the nicest from an abstract code
> structure point of view, but it requires a lot of information that is
> not derived until later.
> It might be possible to treat "ignore the RHS" as a join strategy and
> try to apply it while forming join relations, which would be late enough
> to have all the needed info available.
Oh, actually have a join node that is a no-op, with a path cost of zero?
So we end up with an EXPLAIN like this:
QUERY
PLAN
---------------------------------------------------------------------------------------
Join Removed (cost=0.00..8.27 rows=1 width=4)
-> Index Scan using class_pkey on class c (cost=0.00..8.27 rows=1
width=8)
Index Cond: (pk = 6)
-> No Operation on subclass sc (cost=0.00..0.00 rows=0 width=0)
(4 rows)
That really does help, I think. The code allows us to say a join is
impossible, but not very easily to say a join doesn't exist.
I'll try it this way first. Maybe we'll see other ways as we go.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
