Re: Join Removal/ Vertical Partitioning

On Thu, 2008-06-26 at 13:42 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndquadrant.com> 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.comPostgreSQL Training, Services and Support