Heikki Linnakangas <hlinnaka@iki.fi> writes:
> On 10/13/2017 02:08 AM, Tom Lane wrote:
>> I started to look into fixing orderedsetaggs.c so that we could revert
>> 52328727b, and soon found a rather nasty problem. Although the plain
>> OSAs seem amenable to supporting multiple finalfn calls on the same
>> transition state, the "hypothetical set" functions are not at all.
>> What they do is to accumulate all the regular aggregate input into
>> a tuplesort, then add the direct arguments as an additional "hypothetical"
>> row, and finally sort the result. There's no realistic way of undoing
>> the addition of the hypothetical row, so these finalfns simply can't
>> share tuplesort state.
> The current implementation, with the extra flag column, is quite naive.
> We could add some support to tuplesort to find a row with given
> attributes, and call that instead of actually adding the hypothetical
> row to the tuplesort and iterating to re-find it after performsort. For
> a result set that fits in memory, you could even do a binary search
> instead of linearly iterating through the result set.
I'd had some idle thoughts about using a heap to support window
aggregation of an OSA, rather than ever performing a full sort.
It'd probably work well as long as the window doesn't get wide enough
that the heap stops fitting in memory. But in any case, the immediate
point is that we shouldn't just assume that every aggregate
implementation is capable of supporting state merging, and while we're
at it, it'd be better to have a non-syntax-based distinction between
aggs that can support use as window functions and aggs that can't.
Moving on to the exact color of the bikeshed: it seems like the right
way to present this to users of CREATE AGGREGATE is in terms of "does
the final function modify the transition state?". So maybe the values
could be spelled
SMODIFY = READ_ONLY ffunc never touches state, ok as window agg
SMODIFY = SHARABLE ffunc does some one-time change like sorting, so state merging is OK but not
windowagg
SMODIFY = READ_WRITE ffunc trashes state, can't do merging either
I'm not set on these names by any means; anyone have a better idea?
Also, I'm not sure whether we'd need a separate MMODIFY flag for
the moving-aggregate sub-implementation, but it seems possible.
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