Re: Removing INNER JOINs
От | Atri Sharma |
---|---|
Тема | Re: Removing INNER JOINs |
Дата | |
Msg-id | CAOeZVicW5gp0eGb1M5hLqpGEPryrBkLcm9imCcq354N_uPGaEg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Removing INNER JOINs (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Removing INNER JOINs
|
Список | pgsql-hackers |
On Wed, Dec 3, 2014 at 11:38 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Yeah; moreover, there's no evidence that hard-wiring such assumptionsStephen 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..
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
В списке pgsql-hackers по дате отправления: