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

From: Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Florian Pflug <fgp(at)phlo(dot)org>, David Rowley <dgrowleyml(at)gmail(dot)com>, Kevin Grittner <kgrittn(at)ymail(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-04-10 18:36:37
Message-ID: CAEZATCVBn9_YvE_bs80YhUf8iXhJoq3FLgt=TMXWdWbnPabSTg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10 April 2014 19:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> writes:
>> On 10 April 2014 15:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This idea of a separate firsttrans function is interesting but perhaps
>>> orthogonal to the current patch. Also, I don't quite understand how
>>> it would work for aggregates with null initvalues; don't you end up
>>> with exactly the same conflict about how you can't mark the transfn
>>> strict? Or is the idea that firsttrans would *only* apply to aggregates
>>> with null initvalue, and so you wouldn't even pass the previous state
>>> value to it?
>
>> I was imagining that firsttrans would only be passed the first value
>> to be aggregated, not any previous state, and that it would be illegal
>> to specify both an initcond and a firsttrans function.
>
> Got it. So the existing behavior where we insert the first non-null
> value could be seen as a degenerate case in which the firsttrans function
> is an identity.
>

Right.

>> The forward transition function would only be called for values after
>> the first, by which point the state would be non-null, and so it could
>> be made strict in most cases. The same would apply to the invertible
>> transition functions, so they wouldn't have to do null counting, which
>> in turn would make their state types simpler.
>
> Makes sense to me. We need names for these things though. I don't
> think abbreviating to "ffunc" is a good idea because of the likelihood
> of confusion with the finalfunc (indeed I see the CREATE AGGREGATE
> ref page is already using "ffunc" as a short form for finalfunc).
> Maybe "initfunc", which would parallel "initcond"?
>

Yes, I was already thinking that "initfunc" is actually a much better
name for that.

> What about names for the invertible-aggregate infrastructure?
> I'm tempted to prefix "inv" to all the existing names, but then
> "invsfunc" means the alternate forward function ... can we use
> "invifunc" for the inverse transition function? Or maybe the
> prefix should be just "i".
>

Hmm, I'm not a fan of any of those names. Perhaps "win" as a prefix to
denote a sliding window? Or just "m" for "moving aggregate".

Regards,
Dean

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-04-10 18:54:02 Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Previous Message Tom Lane 2014-04-10 18:04:49 Re: [PATCH] Negative Transition Aggregate Functions (WIP)