Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c) - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)
Date
Msg-id 20200917200951.pfjgiit4ygjvmmen@development
Whole thread Raw
In response to Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)  (Ranier Vilela <ranier.vf@gmail.com>)
Responses Re: Planner, check if can use consider HASH for groupings (src/backend/optimizer/plan/planner.c)
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: WIP: BRIN multi-range indexes
Next
From: Tom Lane
Date:
Subject: Re: factorial function/phase out postfix operators?