Re: Potential performance issues related to group by and covering index

>
> If we want to do anything much smarter than that like trying every
> combination of the GROUP BY clause, then plan times are likely going
> to explode. The join order search is done based on the chosen query
> pathkeys, which in many queries is the pathkeys for the GROUP BY
> clause (see standard_qp_callback()). This means throughout the join
> search, planner will try and form paths that provide pre-sorted input
> that allows the group by to be implemented efficiently with pre-sorted
> data. You might see Merge Joins rather than Hash Joins, for example.
>

Are there guidelines or principles you could share about writing the group
by clause such that it is more efficient?