From: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | David Fetter <david(at)fetter(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: proposal: tuplestore, tuplesort aggregate functions |
Date: | 2010-08-18 14:46:57 |
Message-ID: | AANLkTi=zdEcnsH3EU4dRETP+NaTyAk0gKRnnfZfwyPn9@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2010/8/18 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> David Fetter <david(at)fetter(dot)org> writes:
>> Apart from the medians, which "median-like" aggregates do you have in
>> mind to start with? If you can provide examples of "median-like"
>> aggregates that people might need to implement as user-defined
>> aggregates, or other places where people would use this machinery, it
>> will make your case stronger for this refactoring.
>
> There would be plenty of scope to re-use the machinery without any
> SQL-level extensions. All you need is a polymorphic aggregate
> transition function that maintains a tuplestore or whatever.
> I don't see that extra syntax in CREATE AGGREGATE is really buying
> much of anything.
>
Have we to use a transisdent function? If we implement median as
special variant of aggregate - because we need to push an sort, then
we can skip a transident function function - and call directly final
function. This mechanism is used for aggregates with ORDER BY now. So
there can be a special path for direct call of final func. There is
useles to call transident function.
Regards
Pavel
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2010-08-18 14:54:57 | Re: proposal: tuplestore, tuplesort aggregate functions |
Previous Message | David Fetter | 2010-08-18 14:44:39 | Re: proposal: tuplestore, tuplesort aggregate functions |