Re: Removing INNER JOINs - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Removing INNER JOINs
Date
Msg-id CAOeZVieWbJvJD5KZu2Pc+7E=6j4dDH-m6Lh6QX8J+sR2bggDig@mail.gmail.com
Whole thread Raw
In response to Re: Removing INNER JOINs  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Removing INNER JOINs  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers


On Wed, Dec 3, 2014 at 11:19 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Atri Sharma <atri.jiit@gmail.com> writes:
> 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 think you assume wrong; or at least, I certainly would not wish to
hard-wire any such assumption.  Skipping some joins could change the
shape of the join tree *completely*, because the cost estimates will
change so much.  And that could in turn lead to making different choices
of scan methods, eg, we might or might not care about sort order of
a scan result if we change join methods.

                        regards, tom lane

Agreed, but in some cases, we could possibly make some assumptions (if there is no index, if a large fraction of table will be returned in scan, FunctionScan).

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removing INNER JOINs
Next
From: Stephen Frost
Date:
Subject: Re: Removing INNER JOINs