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

Re: Window-functions patch handling of aggregates

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
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 17:31:05
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> 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?

No.  The entire point of what we have now formalized as "aggregates with
internal-type transition values" is that the transition value isn't
necessarily a single palloc chunk.  For stuff like array_agg, the
performance costs of requiring that are enormous.

On looking at what array_agg does, it seems the issue there is that
the final-function actually deletes the working state when it thinks
it's done with it (see construct_md_array).   It would probably be
possible to fix things so that it doesn't do that when it's called by
a WindowAgg instead of a regular Agg.  What I'm more concerned about
is what third-party code will break.  contrib/intagg has done this
type of thing since forever, and I'm sure people have copied that...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: David Lee LambertDate: 2008-12-24 18:08:01
Subject: Re: uuids on freebsd
Previous:From: Tom LaneDate: 2008-12-24 16:16:33
Subject: Re: generic reloptions improvement

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