Re: Join Removal/ Vertical Partitioning

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Join Removal/ Vertical Partitioning
Date: 2008-06-27 08:31:43
Message-ID: 1214555503.3845.284.camel@ebony.site
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tino Wildenhain 2008-06-27 08:34:22 Re: Posting to hackers and patches lists
Previous Message Simon Riggs 2008-06-27 08:12:01 Re: Building PostgreSQL 8.3.1 on OpenVMS 8.3 AXP