Re: Join Removal/ Vertical Partitioning - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Join Removal/ Vertical Partitioning
Date
Msg-id 18593.1214502169@sss.pgh.pa.us
Whole thread Raw
In response to Join Removal/ Vertical Partitioning  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: Join Removal/ Vertical Partitioning
Re: Join Removal/ Vertical Partitioning
List pgsql-hackers
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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: plpgsql: Is ELSE IF supported or not?
Next
From: Simon Riggs
Date:
Subject: Re: Planner creating ineffective plans on LEFT OUTER joins