From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org, "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com> |
Subject: | Re: Window-functions patch handling of aggregates |
Date: | 2008-12-24 04:18:58 |
Message-ID: | 87y6y6ryrx.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> The window functions patch is laboring under the delusion that it can
> call an aggregate's final function and then go back to invoking the
> transfn some more on the same data. This is merest fantasy :-(
>
> regression=# select array_agg(q1) over(order by q1) from int8_tbl;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting reset: Failed.
>
> Unless we want to move the goalposts on what an aggregate is allowed
> to do internally, we're going to have to change this to re-aggregate
> repeatedly. Neither prospect is appetizing in the least.
Does it currently copy the state datum before calling the final function?
Would that help?
It does seem like the abstract interface we have for aggregate functions is a
strength and we should leverage that. The burden of supporting more complex
cases should be borne by the users that are bending the rules.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2008-12-24 04:59:19 | Re: Hot standby and b-tree killed items |
Previous Message | Tom Lane | 2008-12-24 03:20:45 | Window-functions patch handling of aggregates |