Re: Removing INNER JOINs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: 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:33:43
Message-ID: 19367.1417628023@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Atri Sharma 2014-12-03 17:40:53 Re: Removing INNER JOINs
Previous Message Stephen Frost 2014-12-03 17:22:01 Re: Removing INNER JOINs