Re: a path towards replacing GEQO with something better
От | Tom Lane |
---|---|
Тема | Re: a path towards replacing GEQO with something better |
Дата | |
Msg-id | 759478.1623862383@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: a path towards replacing GEQO with something better (John Naylor <john.naylor@enterprisedb.com>) |
Список | pgsql-hackers |
John Naylor <john.naylor@enterprisedb.com> writes: > On Wed, Jun 16, 2021 at 12:01 PM Robert Haas <robertmhaas@gmail.com> wrote: >> 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. Yeah, I'm not sure I believe this distinction either. IMV a typical star schema is going to involve joins of dimension-table ID columns to *different* referencing columns of the fact table(s), so that you won't get large equivalence classes. There certainly are cases where a query produces large equivalence classes that will lead us to investigate a lot of join paths that we wouldn't have considered were it not for the EC-deduced join clauses. But I don't think that scenario has much to do with star schemas. regards, tom lane
В списке pgsql-hackers по дате отправления: