Re: GROUPING

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: GROUPING
Дата
Msg-id 87617n12yh.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: GROUPING  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: INSERT ... ON CONFLICT UPDATE/IGNORE 4.0
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: jsonb concatenate operator's semantics seem questionable