Re: POC: GROUP BY optimization

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: POC: GROUP BY optimization
Дата
Msg-id 8260d372-8826-31ef-68e6-a7ff8a7265d9@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: POC: GROUP BY optimization  (Teodor Sigaev <teodor@sigaev.ru>)
Ответы Re: POC: GROUP BY optimization  (Teodor Sigaev <teodor@sigaev.ru>)
Список pgsql-hackers
On 06/07/2018 03:41 PM, Teodor Sigaev wrote:
 >>
>> ... snip ...
 >>
>>> Priorization of the user-provided order can be as simple as giving
>>> that comparison_cost a small handicap.
>>
>> I see no point in doing that, and I don't recall a single place in the
>> planner where we do that. If the user specified ORDER BY, we'll slap an
>> explicit Sort on top when needed (which acts as the handicap, but in a
>> clear way). Otherwise we don't do such things - it'd be just plain
>> confusing (consider "ORDER BY a,b" vs. "ORDER BY b,c" with same data
>> types, ndistinct etc. but unexpectedly different costs). Also, what
>> would be a good value for the handicap?
> 
> Again agree. If we have fixed order of columns (ORDER BY) then we should 
> not try to reorder it. Current patch follows that if I didn't a mistake.
> 

This part seems to be more a misunderstanding between me and Claudio. I 
believe Claudio was referring to the column order in a GROUP BY, not 
ORDER BY. In which case we don't add any Sort, of course.

I'm still opposed to adding arbitrary handicap to prioritize the order 
specified by user, for the reasons I explained before. We should aim to 
make the heuristics/costing reliable enough to make this unnecessary.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Sergey Cherkashin
Дата:
Сообщение: Re: processSQLNamePattern() analog
Следующее
От: Teodor Sigaev
Дата:
Сообщение: Re: POC: GROUP BY optimization