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 по дате отправления: