| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> | 
|---|---|
| To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: Combining Aggregates | 
| Date: | 2015-02-24 19:15:51 | 
| Message-ID: | 54ECCDE7.1070509@gmx.net | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
On 2/20/15 3:32 PM, Tomas Vondra wrote:
>> That's just because the count is hidden there in an opaque custom 
>> transition function. If, say, we had instead an array of transition 
>> functions {inc, plus, plussq} and we knew that plus and plussq are 
>> associative operators, all we'd need to special case is the count
>> case. This would avoid a lot of repetitive code for stddev, avg, etc.
> 
> Ummm, I'm not entirely sure I understand that, but the main point was
> that the current implementation does not work like that. We have no idea
> what transition functions are transitive, and we do have opaque
> aggregate states.
Well, my point is that you could make it work that way and make your
current patch a lot smaller and simpler.
> Also, there are aggregate functions like array_agg() or string_agg()
> that make this impossible, just like for many custom aggregates (like
> hyperloglog for example). Again, I might not understand the idea
> correctly ...
How would a combining function work for something like array_agg()?  I
don't think it would, at least if you want to preserve the ordering
option for the user.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Josh Berkus | 2015-02-24 19:16:02 | Re: mogrify and indent features for jsonb | 
| Previous Message | Peter Eisentraut | 2015-02-24 19:12:40 | Re: Precedence of NOT LIKE, NOT BETWEEN, etc |