Re: Partial Mode in Aggregate Functions

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Marcos Pegoraro <marcos(at)f10(dot)com(dot)br>
Cc: David Rowley <dgrowleyml(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Partial Mode in Aggregate Functions
Date: 2026-03-01 15:32:02
Message-ID: CAKFQuwZVxp0EtiHfNiSvAZHBR6D9OCKpHa6fUk7tQqO9yRqdmQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Mar 1, 2026 at 7:55 AM Marcos Pegoraro <marcos(at)f10(dot)com(dot)br> wrote:

> Em dom., 1 de mar. de 2026 às 11:29, David G. Johnston <
> david(dot)g(dot)johnston(at)gmail(dot)com> escreveu:
>
>> I can’t come up with a better header than Partial Mode.
>>
>
> The problem is that if they conclude that there is no FILTER for that
> aggregate,
> they decide to run two queries, not the most readable or the most
> performant one.
> with Data as (select V from MyTable where F1 = 100)
> select (select jsonb_agg(V) from Data) Total,
> (select jsonb_agg(V) from MyTable where V>1) Filtered;
>
>
I'm willing to entertain ideas, but for the proposed scenario I'm quite
content to take the "not our problem" attitude here. As you say, it's
suboptimal, not wrong. And it seems to me an unlikely real world outcome
worth bending over backwards to accommodate based on theory alone.

I'm much more amenable to trying to make clear that FILTER exists, and in
the process point out how/that it differs from Partial Mode.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-03-01 15:43:54 Re: pg_stat_statements: Add gc_count and query_file_size to pgss_info
Previous Message Tomas Vondra 2026-03-01 15:03:36 Re: index prefetching