Re: [PATCH] Negative Transition Aggregate Functions (WIP) - Mailing list pgsql-hackers

From Florian Pflug
Subject Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Date
Msg-id 6A32D596-3C32-4D7F-9ABD-2501B984903A@phlo.org
Whole thread Raw
In response to Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Jan10, 2014, at 15:49 , Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Florian Pflug <fgp@phlo.org> writes:
>> 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?

That's not true, I think, unless we're special-casing strict transition
functions somewhere. AFAICS, an aggregate with a strict transition function
will produce the state NULL whenever any of the inputs was NULL, i.e. we won't
ever transition out of the NULL state once we got there. The inverse
transition function, however, would *have* to be able to transition away
from the NULL state, which requires it to be non-strict. Otherwise, how would
the state aver become non-NULL after the last NULL input leaves the window?

best regards,
Florian Pflug




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Fixing pg_basebackup with tablespaces found in $PGDATA
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)