| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
| Cc: | jian he <jian(dot)universality(at)gmail(dot)com>, Tender Wang <tndrwang(at)gmail(dot)com>, Paul George <p(dot)a(dot)george19(at)gmail(dot)com>, Andy Fan <zhihuifan1213(at)163(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Eager aggregation, take 3 |
| Date: | 2024-12-04 14:38:30 |
| Message-ID: | CA+Tgmoa5WbO+GbmZtb6Y1-J75EA6poGjsQHFYR62_N0iQzGMCA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Nov 10, 2024 at 7:52 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> 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.
Returning to this point now that I understand what you meant by
grouped aggregation:
I still don't understand how you expect to be able to evaluate
functions like LEAD() and LAG() if any form of partial aggregation has
been done.
--
Robert Haas
EDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2024-12-04 14:39:41 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
| Previous Message | Daniel Gustafsson | 2024-12-04 14:33:46 | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |