From: | Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
---|---|
To: | Antonin Houska <ah(at)cybertec(dot)at> |
Cc: | legrand legrand <legrand_legrand(at)hotmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WIP: Aggregation push-down |
Date: | 2020-04-22 03:39:58 |
Message-ID: | CAKU4AWr7m8WWBJS_s3fzc460VQOibXGwtzeRPX8oq6ez9dSVng@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
[1] https://www.postgresql.org/message-id/9726.1542577439@sss.pgh.pa.us
Best Regards
Andy Fan
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-04-22 03:45:08 | Re: WAL usage calculation patch |
Previous Message | David Rowley | 2020-04-22 03:22:14 | Re: Parallel Append can break run-time partition pruning |