Re: a path towards replacing GEQO with something better

Поиск
Список
Период
Сортировка
От John Naylor
Тема Re: a path towards replacing GEQO with something better
Дата
Msg-id CAFBsxsFZgRxJEbJsbRFVDis6bQFL8GSEHjZdC+eLkKS8r5116A@mail.gmail.com
обсуждение исходный текст
Ответ на Re: a path towards replacing GEQO with something better  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: a path towards replacing GEQO with something better  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers


On Wed, Jun 16, 2021 at 12:01 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jun 15, 2021 at 2:16 PM John Naylor
> <john.naylor@enterprisedb.com> wrote:
> > > I don't quite understand the difference between the "chain" case and
> > > the "star" case. Can you show sample queries for each one? e.g. SELECT
> > > ... FROM a_1, a_2, ..., a_n WHERE <something>?
> >
> > SELECT  *
> > FROM    tab1, tab2, tab3, tab4
> > WHERE   tab1.col = tab2.col AND
> >     tab2.col = tab3.col AND
> >     tab3.col = tab4.col
> >
> > SELECT  *
> > FROM    tab1, tab2, tab3, tab4
> > WHERE   tab1.col = tab2.col AND
> >     tab1.col = tab3.col AND
> >     tab1.col = tab4.col
>
> I feel like these are completely equivalent. Either way, the planner
> is going to deduce that all the ".col" columns are equal to each other
> via the equivalence class machinery, and then the subsequent planning
> will be absolutely identical. Or am I missing something?

I believe the intention of the example is that ".col" is a place holder for some column (all different). Otherwise, with enough ECs it would result in an even bigger set of joinrels than what we see here. If ECs don't actually cause additional joinrels to be created, then I'm missing something fundamental.

--
John Naylor
EDB: http://www.enterprisedb.com

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

Предыдущее
От: Yugo NAGATA
Дата:
Сообщение: Re: Avoid stuck of pbgench due to skipped transactions
Следующее
От: Tom Lane
Дата:
Сообщение: Allowing regular identifiers in isolationtester scripts