Skip site navigation (1) Skip section navigation (2)

Re: Window-functions patch handling of aggregates

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: (view raw, whole thread or download thread mbox)
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
  Ask me about EnterpriseDB's PostGIS support!

In response to


pgsql-hackers by date

Next:From: Robert TreatDate: 2008-12-24 04:59:19
Subject: Re: Hot standby and b-tree killed items
Previous:From: Tom LaneDate: 2008-12-24 03:20:45
Subject: Window-functions patch handling of aggregates

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group