On Tue, Jun 25, 2024 at 13:08:45 -0400,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
>Not really. It will work that way in simple cases, but I think the
>behavior stops being predictable if the input gets large enough to
>induce the planner to use parallel aggregation. In any case, the
>example shown isn't amazingly efficient since it'll still perform
>a sort to meet the ORDER BY spec.
Thanks.
>> The use case is that I want to return a value of one column that is paired
>> with the maximum value of another column in each group when using GROUP BY.
>
>Use window functions (i.e. first_value). This is what they're for,
>and they are smart enough to do just one sort for functions sharing
>a common window spec.
If I do that, I'd need to do it as a subselect inside of a group by. I'm
thinking distinct on may work and be a better way to do it. The actual
use case is a set of tripplets returned from a query, where I want on
row for each distinct value in the first column, paired with the value
in the second column, for which the third column is the largest. The
second and third columns are effectively dependent on each other, so there
won't be any ambiguity.
Thanks for getting me thinking about some other ways to approach the problem.
