Re: Sharing aggregate states between different aggregate functions

On 27 July 2015 at 20:11, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 07/27/2015 08:34 AM, David Rowley wrote:
>
> In this function I also wasn't quite sure if it was with comparing both
>> non-NULL INITCOND's here. I believe my code comments may slightly
>> contradict what the code actually does, as the comments talk about them
>> having to match, but the code just bails if any are non-NULL. The reason I
>> didn't check them was because it seems inevitable that some duplicate work
>> needs to be done when setting up the INITCOND. Perhaps it's worth it?
>>
>
> It would be nice to handle non-NULL initconds. I think you'll have to
> check that the input function isn't volatile. Or perhaps just call the
> input function, and check that the resulting Datum is byte-per-byte
> identical, although that might be awkward to do with the current code
> structure.
>
>
Yeah, it's awkward, as I just managed to remind myself:

The aggtranstype needs to be known before we can call GetAggInitVal() on
the initval datum.

That currently happens in build_transstate_for_aggref() only when we've
decided to create a new state.

transstate->initValue = GetAggInitVal(textInitVal,
transstate->aggtranstype);

And to get the aggtranstype:

transstate->aggtranstype =
resolve_aggregate_transtype(aggref->aggfnoid,
aggform->aggtranstype,
inputTypes,
numArguments);

Of course, not impossible, but lots of code gets duplicated.

Regards

David Rowley

--
David Rowley http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Training & Services