Re: [HACKERS] partial aggregation with internal state type

2017-06-09 Thread Tom Lane
Jeff Janes  writes:
> On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane  wrote:
>> The issue is how to initialize the state value to begin with.

> Why does it need to be initialized?  initializing a NULL state upon first
> use is already the job of sfunc.

Right, but for partial aggregation the combinefunc has the same kind of
role as the sfunc.

> Can't it just be left NULL if both inputs
> are NULL?  (and use serialize/deserialize to change the memory context of
> the not-NULL argument if one is NULL and one is not NULL)

Huh?  That would assume that the deserialize function is identical to what
the combinefunc would do for the first input.  I'm not sure it's even the
right abstract type signature for that.  I think you're also assuming too
much about what the combine and deserialize functions will do in terms
of memory context usage.

In the end it's not very clear to me what you hope to gain here.  It's
not like there's any chance of omitting the combinefunc altogether.
Requiring it to do something sane with a NULL initial combined state
doesn't seem like much of a burden.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


Re: [HACKERS] partial aggregation with internal state type

2017-06-09 Thread Jeff Janes
On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane  wrote:

> Jeff Janes  writes:
> > The docs for creating aggregates for 9.6 and beyond say:
> > "For aggregate functions whose state_data_type is internal, the
> combinefunc
> > must not be strict. In this case the combinefunc must ensure that null
> > states are handled correctly and that the state being returned is
> properly
> > stored in the aggregate memory context."
>
> > Since combinefunc with an internal type is only useful when serialfunc
> and
> > deserialfunc are also defined, why can't the built-in machinery just do
> the
> > right thing when faced with a strict combinefunc?
>
> The issue is how to initialize the state value to begin with.
>

Why does it need to be initialized?  initializing a NULL state upon first
use is already the job of sfunc.  Can't it just be left NULL if both inputs
are NULL?  (and use serialize/deserialize to change the memory context of
the not-NULL argument if one is NULL and one is not NULL)


Cheers,

Jeff


Re: [HACKERS] partial aggregation with internal state type

2017-06-09 Thread Tom Lane
Jeff Janes  writes:
> The docs for creating aggregates for 9.6 and beyond say:
> "For aggregate functions whose state_data_type is internal, the combinefunc
> must not be strict. In this case the combinefunc must ensure that null
> states are handled correctly and that the state being returned is properly
> stored in the aggregate memory context."

> Since combinefunc with an internal type is only useful when serialfunc and
> deserialfunc are also defined, why can't the built-in machinery just do the
> right thing when faced with a strict combinefunc?

The issue is how to initialize the state value to begin with.

I suppose you're imagining that we could fill pg_aggregate.agginitval
with something that the serialfunc could read.  But that would place
serious constraints on the serialization format, like that it be
machine-independent and valid as text.

regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers


[HACKERS] partial aggregation with internal state type

2017-06-09 Thread Jeff Janes
The docs for creating aggregates for 9.6 and beyond say:

"For aggregate functions whose state_data_type is internal, the combinefunc
must not be strict. In this case the combinefunc must ensure that null
states are handled correctly and that the state being returned is properly
stored in the aggregate memory context."

Since combinefunc with an internal type is only useful when serialfunc and
deserialfunc are also defined, why can't the built-in machinery just do the
right thing when faced with a strict combinefunc?

Cheers,

Jeff