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

Предыдущее
От: David Rowley
Дата:
Сообщение: Re: Parallel Append can break run-time partition pruning
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: WAL usage calculation patch