Re: Removing INNER JOINs

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

> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Atri Sharma (atri(dot)jiit(at)gmail(dot)com) wrote:
> >> 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).
>
> > All neat ideas but how about we get something which works in the way
> > being asked for before we start trying to optimize it..? Maybe I'm
> > missing something, but getting all of this infrastructure into place and
> > making sure things aren't done to the plan tree which shouldn't be (or
> > done to all of them if necessary..) is enough that we should get that
> > bit done first and then worry if there are ways we can further improve
> > things..
>
> Yeah; moreover, there's no evidence that hard-wiring such assumptions
> would save anything. In the example of a FunctionScan, guess what:
> there's only one Path for that relation anyway.
>
> That is precisely what I meant :) I guess I was being too over cautious
and even trying to save the time spent in evaluating whatever paths we have
and building new FunctionScan paths...

> I think the right approach for now is to emulate the GEQO precedent as
> closely as possible. Build all the single-relation Paths the same as
> now, then do a join search over all the relations, then (if we've noticed
> that some joins are potentially removable) do another join search over
> just the nonremovable relations.
>

How about using geqo more liberally when replanning (decrease the number of
relations in join before geqo is hit?)

--
Regards,

Atri
*l'apprenant*