Re: [PATCH] Negative Transition Aggregate Functions (WIP)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Greg Stark <stark(at)mit(dot)edu>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date: 2014-01-10 14:49:35
Message-ID: 11275.1389365375@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Florian Pflug <fgp(at)phlo(dot)org> writes:
> On Jan10, 2014, at 09:34 , David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
>> I just don't quite know yet the base way for the inverse transition function to communicate this to the caller yet. If you have any ideas on the best way to do this then I'd really like to hear them.

> Could they maybe just return NULL as the new state? It would mean that
> aggregates that do want to provide an inverse transition function couldn't
> use NULL as a valid aggregate state, but do we need to support that?

Yeah, I was going to suggest the same. Seems like it wouldn't be that
difficult to come up with some alternative representation for "everything
seen so far was NULL", if you needed to.

> Looking at the code it seems that for quite a few existing aggregates,
> the state remains NULL until the first non-NULL input is processed. But
> that doesn't hurt much - those aggregates can remain as they are until
> someone wants to add an inverse transfer function. Once that happens,
> there's a choice between living with needless rescans on trailing NULL
> inputs or changing the state type.

Also, it might be reasonable for both the regular and the inverse
transition functions to be strict. If a null entering the window
does not matter, then a null exiting the window doesn't either, no?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-01-10 15:09:33 Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Previous Message Kadri Raudsepp 2014-01-10 14:31:48 Column missing from pg_statistics