Re: Combining Aggregates

On 24 December 2015 at 14:07, Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com>
wrote:

> On Wed, Dec 23, 2015 at 7:50 PM, David Rowley
> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> > This is just my serial format that I've come up with for NumericAggState,
> > which is basically: "N sumX maxScale maxScaleCount NaNcount". Perhaps we
> can
> > come up with something better, maybe just packing the ints and int64s
> into a
> > bytea type and putting the text version of sumX on the end... I'm sure we
> > can think of something more efficient between us, but I think the serial
> > state should definitely be cross platform e.g if we do the bytea thing,
> then
> > the ints should be in network byte order so that a server cluster can
> have a
> > mix of little and big-endian processors.
>
> Instead of adding serial and de-serial functions to all aggregates which
> have
> transition type as internal, how about adding these functions as send and
> recv functions for internal type? can be used only in aggregate context.
> The data can send and receive similar like other functions. Is it possible?

The requirement that needs to be met is that we have the ability to
completely represent the INTERNAL aggregate state inside a tuple. It's
these tuples that are sent to the main process in the parallel aggregate
situation, and also in Sorted and Plain Aggregate too, although in the case
of Sorted and Plain Aggregate we can simply put the pointer to the INTERNAL
state in the tuple, and this can be dereferenced.

Perhaps I'm lacking imagination, but right now I'm not sure how send and
recv functions can be used to help us here. Although we perhaps could make
serial and deserial functions skip on type conversions by using similar
methods as to what's used in send and recv.

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