Обсуждение: [HACKERS] partial aggregation with internal state type

Поиск
Список
Период
Сортировка

[HACKERS] partial aggregation with internal state type

От
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

Re: [HACKERS] partial aggregation with internal state type

От
Tom Lane
Дата:
Jeff Janes <jeff.janes@gmail.com> 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



Re: [HACKERS] partial aggregation with internal state type

От
Jeff Janes
Дата:
On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Jeff Janes <jeff.janes@gmail.com> 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

От
Tom Lane
Дата:
Jeff Janes <jeff.janes@gmail.com> writes:
> On Fri, Jun 9, 2017 at 9:06 AM, Tom Lane <tgl@sss.pgh.pa.us> 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