Re: Combining Aggregates

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Feb 24, 2015 at 2:20 PM, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
>> 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.

FWIW, I agree with Robert. It's better to keep this in pg_aggregate.
We don't need yet another mostly-empty column in pg_proc; and as for
pg_operator, there is no expectation that an aggregate transition function
is in pg_operator.

Also, I don't think it's a foregone conclusion that same transition
function implies same combiner function: that logic falls apart when
you consider that one of them might be polymorphic and the other not.
(Admittedly, that probably means the aggregate creator is missing a bet;
but we should not design the catalog schema in a way that says that only
maximally efficient aggregate designs are allowed.)

regards, tom lane