Re: Removing INNER JOINs - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Removing INNER JOINs
Date
Msg-id 20454.1417630088@sss.pgh.pa.us
Whole thread Raw
In response to Re: Removing INNER JOINs  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Removing INNER JOINs  (Atri Sharma <atri.jiit@gmail.com>)
List pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> * Atri Sharma (atri.jiit@gmail.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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: Removing INNER JOINs
Next
From: Alvaro Herrera
Date:
Subject: Re: tracking commit timestamps