On Sun, Nov 10, 2024 at 7:52 PM Richard Guo <guofengli...@gmail.com> wrote: > > I have similar but weaker feelings about ordered aggregates. Consider: > > > > explain select t1.id, array_agg(t2.v order by t3.o) from t1, t2, t3 > > where t1.id = t2.id and t2.id = t3.id group by 1; > > > > It seems to me that a partially aggregated row might need to be > combined with other partially aggregated rows after the join, if they > belong to the same t1.id group. IIUC, this implies that we cannot > perform partial aggregation on ordered input before the join, > otherwise we may get incorrect results during the final aggregation > phase.
Hmm, I think you're right. I think that if the t1.id=t2.id join is one to one, then it would work out fine, but that need not be the case. > Hmm, currently we only consider grouped aggregation for eager > aggregation. For grouped aggregation, the window function's > arguments, as well as the PARTITION BY expressions, must appear in the > GROUP BY clause. That is to say, the depname column in the first > query, or the n column in the second query, will not be aggregated > into the partial groups. Instead, they will remain as they are as > input for the WindowAgg nodes. It seems to me that this ensures > that we're good with window functions. But maybe I'm wrong. Unfortunately, I don't know what you mean by grouped aggregation. I think of grouping and aggregation as synonyms, pretty much. -- Robert Haas EDB: http://www.enterprisedb.com
