Re: more support for various frame types of window functions

From: Sam Mason <sam(at)samason(dot)me(dot)uk>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: more support for various frame types of window functions
Date: 2009-11-09 16:47:13
Message-ID: 20091109164712.GJ5407@samason.me.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 09, 2009 at 10:01:53AM -0500, Tom Lane wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> > One idea is to take a copy of the state datum after each row. Then,
> > instead of initializing the aggregate from scratch, you can "roll back"
> > to an earlier copied state. It doesn't always help, but might be a part
> > of the solution.
>
> That requires that you know how to copy the aggregate's state. You do
> not. (In some cases the aggregate function has extra state besides the
> nominal transition datum...)

Other ways of doing aggregates/folds involve exploiting a "tree" like
structure (mostly for reasons of parallelism, but these don't apply to
PG). For example, instead of having the triple (init,accum,final) as we
do at the moment, you could have a "merge" function that would take two
intermediate states and combine them. For example, COUNT and SUM would
be the add function, MIN and MAX would be least and greatest functions
respectively, and so on.

If this method exists then you can do the fancy stuff as suggested, if
it doesn't exist then fall back to less optimal methods.

--
Sam http://samason.me.uk/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2009-11-09 17:12:38 Re: operator exclusion constraints
Previous Message Alexandra Roy 2009-11-09 16:18:12 Re: PostgreSQL 8.3.8 on AIX5.3 : compilation failed