Re: Removing INNER JOINs

From: Atri Sharma <atri(dot)jiit(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Mart Kelder <mart(at)kelder31(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>
Subject: Re: Removing INNER JOINs
Date: 2014-12-03 17:40:53
Message-ID: CAOeZVidR1_JoQA_6xUvnmsZVyzwmZpEEUBwK8R01gc1GaQZg7Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 3, 2014 at 11:03 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> However, even granting that that is a concern, so what? You *have* to
> >> do the planning twice, or you're going to be generating a crap plan for
> >> one case or the other.
>
> > Yeah, I don't see a way around that..
>
> Also, it occurs to me that it's only necessary to repeat the join search
> part of the process, which means that in principle the mechanisms already
> exist for that; see GEQO. This means that for small join problems, the
> total planning time would much less than double anyway. For large
> problems, where the join search is the bulk of the time, we could hope
> that removal of unnecessary joins would reduce the join search runtime
> enough that the second search would be pretty negligible next to the
> first (which is not optional). So I think "it'll double the runtime"
> is an unfounded objection, or at least there's good reason to hope it's
> unfounded.
>
>
Is it possible to only replan part of the plan in case of this
optimization? I think that we might need to only replan parts of the
original plan (as you mentioned, join search and above). So we could reuse
the original plan in part and not do a lot of replanning (an obvious case
is scan strategy, which we can assume will not change for the two plans).

I wonder if we could have a rule based system for replacement of some plan
nodes with other type of nodes. As we discover more cases like this, we
could add more rules. Wild thought though.

--
Regards,

Atri
*l'apprenant*

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-12-03 17:41:57 Re: Removing INNER JOINs
Previous Message Tom Lane 2014-12-03 17:33:43 Re: Removing INNER JOINs