Re: Spilling hashed SetOps and aggregates to disk - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Spilling hashed SetOps and aggregates to disk
Date
Msg-id 4223.1528219621@sss.pgh.pa.us
Whole thread Raw
In response to Re: Spilling hashed SetOps and aggregates to disk  (David Fetter <david@fetter.org>)
Responses Re: Spilling hashed SetOps and aggregates to disk
List pgsql-hackers
David Fetter <david@fetter.org> writes:
> On Tue, Jun 05, 2018 at 02:56:23PM +1200, David Rowley wrote:
>> True. Although not all built in aggregates have those defined.

> Just out of curiosity, which ones don't? As of
> 3f85c62d9e825eedd1315d249ef1ad793ca78ed4, pg_aggregate has both of
> those as NOT NULL.

NOT NULL isn't too relevant; that's just protecting the fixed-width
nature of the catalog rows.  What's important is which ones are zero.

# select aggfnoid::regprocedure, aggkind from pg_aggregate where (aggserialfn=0 or aggdeserialfn=0) and aggtranstype =
'internal'::regtype;
                       aggfnoid                       | aggkind
------------------------------------------------------+---------
 array_agg(anynonarray)                               | n
 array_agg(anyarray)                                  | n
 string_agg(text,text)                                | n
 string_agg(bytea,bytea)                              | n
 json_agg(anyelement)                                 | n
 json_object_agg("any","any")                         | n
 jsonb_agg(anyelement)                                | n
 jsonb_object_agg("any","any")                        | n
 percentile_disc(double precision,anyelement)         | o
 percentile_cont(double precision,double precision)   | o
 percentile_cont(double precision,interval)           | o
 percentile_disc(double precision[],anyelement)       | o
 percentile_cont(double precision[],double precision) | o
 percentile_cont(double precision[],interval)         | o
 mode(anyelement)                                     | o
 rank("any")                                          | h
 percent_rank("any")                                  | h
 cume_dist("any")                                     | h
 dense_rank("any")                                    | h
(19 rows)

Probably the ordered-set/hypothetical ones aren't relevant for this
issue.

Whether or not we feel like fixing the above "normal" aggs for this,
the patch would have to not fail on extension aggregates that don't
support serialization.

            regards, tom lane


pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: [PATCH] Trim trailing whitespace in vim and emacs
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCH] Trim trailing whitespace in vim and emacs