Hi Mr.Momjian, Mr.Haas, hackers. > From: Bruce Momjian <br...@momjian.us> > Sent: Thursday, November 23, 2023 6:16 AM > On Wed, Nov 22, 2023 at 10:16:16AM +0000, > fujii.y...@df.mitsubishielectric.co.jp wrote: > > 2. Approach 2 > > (1) Advantages > > (a) No need to add partial aggregate functions to the catalogs for > > each aggregation > > (2) Disadvantages > > (a) Need to add non-standard keywords to the SQL syntax. > > > > I did not choose Approach2 because I was not confident that the > > disadvantage mentioned in 2.(2)(a) would be accepted by the PostgreSQL > > development community. > > If it is accepted, I think Approach 2 is smarter. > > Could you please provide your opinion on which approach is preferable > > after comparing these two approaches? > > I didn't know #2 was possible, but given the great number of catalog entries, > doing it in the SQL grammar seems cleaner > to me. Thank you for comments. Yes, I understand.
> From: Bruce Momjian <br...@momjian.us> > Sent: Wednesday, November 22, 2023 5:34 AM > On Tue, Nov 21, 2023 at 12:16:41PM -0500, Robert Haas wrote: > > On Mon, Nov 20, 2023 at 5:48 PM Bruce Momjian <br...@momjian.us> wrote: > > > > I do have a concern about this, though. It adds a lot of bloat. It > > > > adds a whole lot of additional entries to pg_aggregate, and every > > > > new aggregate we add in the future will require a bonus entry for > > > > this, and it needs a bunch of new pg_proc entries as well. One > > > > idea that I've had in the past is to instead introduce syntax that > > > > just does this, without requiring a separate aggregate definition in > > > > each case. > > > > For example, maybe instead of changing string_agg(whatever) to > > > > string_agg_p_text_text(whatever), you can say PARTIAL_AGGREGATE > > > > string_agg(whatever) or string_agg(PARTIAL_AGGREGATE whatever) or > > > > something. Then all aggregates could be treated in a generic way. > > > > I'm not completely sure that's better, but I think it's worth > > > > considering. > > > > > > So use an SQL keyword to indicates a pushdown call? We could then > > > automate the behavior rather than requiring special catalog functions? > > > > Right. It would require more infrastructure in the parser, planner, > > and executor, but it would be infinitely reusable instead of needing a > > new thing for every aggregate. I think that might be better, but to be > > honest I'm not totally sure. > > It would make it automatic. I guess we need to look at how big the patch is > to do it. I will investigate specifically which parts of the PostgreSQL source code need to be modified and how big the patch will be if you take this approach. Sincerely yours, Yuuki Fujii -- Yuuki Fujii Information Technology R&D Center Mitsubishi Electric Corporation
