From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Combining Aggregates |
Date: | 2015-03-04 00:00:16 |
Message-ID: | CA+TgmobryNiZ4x7RsMt_hfw302ShaW05vByr6kZD4xQkoedOoA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Feb 24, 2015 at 2:20 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> On 2/20/15 3:09 PM, Tomas Vondra wrote:
>> The 'combine' function gets two such 'state' values, while transition
>> gets 'state' + next value.
>
> I think the combine function is not actually a property of the
> aggregate, but a property of the transition function. If two aggregates
> have the same transition function, they will also have the same combine
> function. The combine function really just says, how do you combine two
> series of these function calls. Say maybe this should be put into
> pg_proc instead. (Or you make the transition functions transition
> operators and put the info into pg_operator instead, which is where
> function call optimization information is usually kept.)
This seems like a weird design to me. It's probably true that if the
transition function is the same, the state-combiner function will also
be the same. But the state-combiner function is only going to exist
for aggregate transition functions, not functions or operators in
general. So linking it from pg_proc or pg_operator feels wrong to me.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2015-03-04 00:14:20 | Re: failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44) |
Previous Message | Robert Haas | 2015-03-03 23:53:20 | Re: failures with tuplesort and ordered set aggregates (due to 5cefbf5a6c44) |