Re: [HACKERS] array_accum aggregate

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > The other issue is, in the above scenario
> > is it acceptable to modify the result of my_sfunc(null, 1) in the ,2
> > call?
>
> Yes, because the only place a nonnull value of the type could have come
> from is a my_sfunc call; since it's a pseudotype, we don't allow it on
> disk. (We might also need a hack to prevent the type from being used as
> a record-type component ... not sure if that comes for free with being a
> pseudotype currently.)

Ah, ok.

> > As for a type for each such aggregate, that seems reasonable to me,
> > honestly.
>
> The ugly part is that we'd still need a way for the planner to recognize
> this class of types.

Hrm, true. I would agree that they would need more memory than most
aggregates. It seems likely to me that worst offenders are going to be
of the array_accum type- store all tuples coming in. Therefore, my
suggestion would be that the memory usage be estimated along those lines
and allow for hashagg when there's enough memory to keep all the tuples
(or rather the portion of the tuple going into the aggregate) in memory
(plus some amount of overhead, maybe 10%). That doesn't help with how
to get the planner to recognize this class of types though. I don't
suppose we already have a class framework which the planner uses to
group types which have similar characteristics?

> > Additionally, we'd have to be
> > able to mark the types as being polymorhpic along the same lines as
> > anyelement/anyarray.
>
> What for?

So that the finalfunc can be polymorphic along the lines of my suggested
aaccum_sfunc(anyarray,anyelement) returns anyarray and
aaccum_ffunc(anyarray) returns anyarray. If the state type isn't
polymorphic then PG won't let me create a function from it which returns
a polymorphic, aiui.

Thanks,

Stephen