Re: Removing INNER JOINs

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: Removing INNER JOINs
Дата
Msg-id 54B6C535.4030608@BlueTreble.com
обсуждение исходный текст
Ответ на Re: Removing INNER JOINs  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Removing INNER JOINs  (David Rowley <dgrowleyml@gmail.com>)
Список pgsql-hackers
On 1/13/15 5:02 AM, David Rowley wrote:
>
> I can't quite get my head around what you mean here, as the idea sounds quite similar to something that's been
discussedalready and ruled out.
 
> If we're joining relation a to relation b, say the plan chosen is a merge join. If we put some special node as the
parentof the merge join then how will we know to skip or not skip any sorts that are there especially for the merge
join,or perhaps the planner choose an index scan as a sorted path, where now that the join is removed, could become a
fasterseqscan. The whole plan switching node discussion came from this exact problem. Nobody seemed to like the
non-optimalplan that was not properly optimised for having the relation removed.
 

In my mind this is the same as a root level Alternative Plan, so you'd be free to do whatever you wanted in the
alternate:

-> blah blah  -> Alternate    -> Merge join       ...    -> SeqScan

I'm guessing this would be easier to code, but that's just a guess. The other advantage is if you can't eliminate the
jointo table A at runtime you could still eliminate table B, whereas a top-level Alternate node doesn't have that
flexibility.

This does have a disadvantage of creating more plan variations to consider. With a single top-level Alternate node
there'sonly one other option. I believe multiple Alternates would create more options to consider.
 

Ultimately, unless this is easier to code than a top-level alternate, it's probably not worth pursuing.

> It also seems that transitioning through needless nodes comes at a cost. This is why I quite liked the Alternative
Plannode idea, as it allowed me to skip over the alternative plan node at plan initialisation.
 

For init I would expect this to result in a smaller number of nodes than a top-level Alternate, because you wouldn't be
duplicatingall the stuff above the joins. That said, I rather doubt it's worth worrying about the cost to init; won't
itbe completely swamped by extra planning cost, no matter how we go about this?
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Stephen Frost
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE and RLS
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pg_basebackup fails with long tablespace paths