Re: WIP: Aggregation push-down
| От | Andy Fan |
|---|---|
| Тема | Re: WIP: Aggregation push-down |
| Дата | |
| Msg-id | CAKU4AWr7m8WWBJS_s3fzc460VQOibXGwtzeRPX8oq6ez9dSVng@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: WIP: Aggregation push-down (Andy Fan <zhihui.fan1213@gmail.com>) |
| Ответы |
Re: WIP: Aggregation push-down
|
| Список | pgsql-hackers |
> 1) v14-0001-Introduce-RelInfoList-structure.patch
> -------------------------------------------------
>
> - I'm not entirely sure why we need this change. We had the list+hash
> before, so I assume we do this because we need the output functions?
I believe that this is what Tom proposed in [1], see "Maybe an appropriate
preliminary patch is to refactor the support code ..." near the end of that
message. The point is that now we need two lists: one for "plain" relations
and one for grouped ones.
I guess what Toms suggested[1] is to store the the grouped ones into
root->upper_rels rather than a separated member, see fetch_upper_rel
or UpperRelationKind. If we do need the list+hash method for long list lookup,
we can merge it into upper_rels. If we want this benefits at other place rather
than root->upper_rels, we can store a generic type in RelInfoList, looks currently
it is bounded to RelAggInfo besides RelOptInfo. But overall, personally I think we can
ignore such optimization at the first stage to save the attention of the core reviewers
since they are too precious :) Just FYI
Best Regards
Andy Fan
В списке pgsql-hackers по дате отправления: