Re: GROUPING - Mailing list pgsql-hackers

From Andrew Gierth
Subject Re: GROUPING
Date
Msg-id 87617n12yh.fsf@news-spur.riddles.org.uk
Whole thread Raw
In response to Re: GROUPING  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
>> I was thinking it should produce NUMERIC rather than int4 as it does>> now in order to accommodate large numbers of
columns,but the>> usefulness of the bitmap is greatly increased if there's a simple>> CAST to bit(n).
 
Tom> Maybe INT8 would be a better choice than INT4?  But I'm not sureTom> there's any practical use-case for more than
30grouping setsTom> anyway.  Keep in mind the actual output volume probably grows likeTom> 2^N.
 

Spec says "The declared type of the result is exact numeric with an
implementation-defined precision and a scale of 0 (zero)."  for what
that's worth.  It doesn't give any hint that I can see for the max
number of columns; it just defines grouping(a...,z) as being equal to
2*grouping(a...) + grouping(z).

But the number of grouping sets isn't really relevant here, rather the
number of columns used for grouping.

In any case, if 31 isn't enough for you, you can call it multiple times:

select ..., grouping(a,b,...,z), grouping(a1,b1,...z1), ...

I didn't think >31 columns would be an issue, but changing it to bigint
is of course trivial if anyone thinks it necessary.

A possibly more interesting question is whether any other db products
have operations like GROUPING() that we could usefully support?

-- 
Andrew (irc:RhodiumToad)



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Next
From: Pavel Stehule
Date:
Subject: Re: jsonb concatenate operator's semantics seem questionable