Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)
От | Tomas Vondra |
---|---|
Тема | Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c) |
Дата | |
Msg-id | 20200917200951.pfjgiit4ygjvmmen@development обсуждение исходный текст |
Ответ на | Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c) (Ranier Vilela <ranier.vf@gmail.com>) |
Ответы |
Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)
|
Список | pgsql-hackers |
On Thu, Sep 17, 2020 at 02:12:12PM -0300, Ranier Vilela wrote: >Hi, > >In case gd->any_hashable is FALSE, grouping_is_hashable is never called. >In this case, the planner could use HASH for groupings, but will never know. > The condition is pretty simple - if the query has grouping sets, look at grouping sets, otherwise look at groupClause. For this to be an issue the query would need to have both grouping sets and (independent) group clause - which AFAIK is not possible. For hashing to be worth considering, at least one grouping set has to be hashable - otherwise it's pointless. Granted, you could have something like GROUP BY GROUPING SETS ((a), (b)), c which I think essentially says "add c to every grouping set" and that will be covered by the any_hashable check. Or how would a query triggering this look like? >Apparently gd pointer, will never be NULL there, verified with Assert(gd != >NULL). > Um, what? If you add the assert right before the if condition, you won't even be able to do initdb. It's pretty clear it'll crash for any query without grouping sets. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: