Re: Final Patch for GROUPING SETS - unrecognized node type: 347

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Final Patch for GROUPING SETS - unrecognized node type: 347
Дата
Msg-id 87lhpv8u9q.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Final Patch for GROUPING SETS - unrecognized node type: 347  (Tomas Vondra <tv@fuzzy.cz>)
Ответы Re: Final Patch for GROUPING SETS - unrecognized node type: 347  (Tomas Vondra <tv@fuzzy.cz>)
Список pgsql-hackers
>>>>> "Tomas" == Tomas Vondra <tv@fuzzy.cz> writes:
>> It's not one sort per grouping set, it's the minimal number of>> sorts needed to express the result as a union of
ROLLUP>>clauses. The planner code will (I believe) always find the>> smallest number of sorts needed.
 
Tomas> You're probably right. Although when doing GROUP BY CUBETomas> (a,b,c,a) I get one more ChainAggregate than
withTomas>CUBE(a,b,c). and we seem to compute all the aggregatesTomas> twice. Not sure if we need to address this
though,becauseTomas> it's mostly user's fault.
 

Hm. Yeah, you're right that the number of sorts is not optimal there.
We can look into that.

As for computing it all twice, there's currently no attempt to
optimize multiple identical grouping sets into multiple projections of
a single grouping set result. CUBE(a,b,c,a) has twice as many grouping
sets as CUBE(a,b,c) does, even though all the extra ones are duplicates.

-- 
Andrew (irc:RhodiumToad)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: Final Patch for GROUPING SETS - unrecognized node type: 347
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Allowing implicit 'text' -> xml|json|jsonb