On Apr10, 2014, at 21:34 , Dean Rasheed <dean.a.rash...@gmail.com> wrote:
> On 10 April 2014 19:54, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> So if we go with that terminology, perhaps these names for the
>> new CREATE AGGREGATE parameters:
>>
>> initfunc applies to plain aggregation, mutually exclusive with
>> initcond
>> msfunc (or just mfunc?) forward transition for moving-agg mode
>> mifunc inverse transition for moving-agg mode
>> mstype state datatype for moving-agg mode
>> msspace space estimate for mstype
>> mfinalfunc final function for moving-agg mode
>> minitfunc "firsttrans" for moving-agg mode
>> minitcond mutually exclusive with minitfunc
>
> I think I prefer "mfunc" to "msfunc", but perhaps that's just my
> natural aversion to the "ms" prefix :-)
>
> Also, perhaps "minvfunc" rather than "mifunc" because "i" by itself
> could mean "initial".
I still think you're getting ahead of yourselves here. The number of
aggregates which benefit from this is tiny SUM(int2,int4) and maybe
BOOL_{AND,OR}. And in the SUM(int2,int4) case *only* on 64-bit archs -
for the others, the state type is already pass-by-ref.
I don't think we should be additional that much additional machinery
until it has been conclusively demonstrated that the performance
regression cannot be fixed any other way. Which, quite frankly, I
don't believe. Nothing in int4_avg_accum looks particularly expensive,
and the things that *do* seem to cost something certainly can be made
cheaper. c.f. the patch I just posted.
Another reason I'm so opposed to this is that inverse transition
functions might not be the last kind of transition functions we ever
add. For example, if we ever get ROLLUP/CUBE, we might want to have
a mergefunc which takes two aggregation states and combines them
into one. What do we do if we add those? Add yet a another set of
"mergable" transition functions? What about the various combinations
of invertible/non-invertible mergable/non-mergable that could result?
The opportunity cost seems pretty high here...
best regards,
Florian Pflug
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
