John Naylor <[email protected]> writes:
> On Wed, Aug 12, 2026 at 11:01 AM Haibo Yan <[email protected]> wrote:
>> I’d like to propose a small optimization for aggregate-local ORDER BY in
>> COUNT.
>> Currently, for example:
>>
>> SELECT count(a ORDER BY b) FROM t;
>>
>> is planned as an ordered aggregate, even though the ordering cannot affect
>> the
>> result of COUNT. This may require a Sort, but the impact is broader than
>> just
>> the extra sort: having aggorder also prevents partial aggregation and hash
>> aggregation, and prevents the aggregate from sharing state with an otherwise
>> identical count(a).
> The question that comes to mind is, why would someone (or a program
> for that matter) write it this way? Self-join elimination cited ORMs
> as a motivation, what is it for this case?
If someone did write that, they might have a good reason to. I don't
think we should expend planner cycles (not to mention development and
code maintenance effort) on looking for such cases.
regards, tom lane
