Re: issues with eager aggregation

On 9/18/26 01:58, Richard Guo wrote:
> On Fri, Sep 18, 2026 at 12:55 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, Sep 17, 2026 at 10:58 AM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
>>> As for the division-by-zero case, I agree it's user-visible, but I
>>> think eager aggregation should follow the same rules as our existing
>>> transformations, which already evaluate expressions on rows that a
>>> join removes.
>
>> OK, good. So this isn't really doing something that is fundamentally
>> new, which is what I was fearing. Do you think this section should be
>> adjusted at all?
>
> Yes, I think it's worth saying that an expression can be evaluated on
> rows that don't appear in the result.
>

How likely is it that a working query starts failing due to flipping to
a plan with eager aggregate?

I realize it's hard to estimate this, but Robert's example with a join
filtering rows may not be all that uncommon. Say, you might be asking
for average price of products currently offered in shops, and it's fine
that a product has no price if it's not being sold. And so on.

And if it happens, how can the user remedy it? I can think of disabling
the eager aggregation, or adding an "OFFSET 0" ...

FWIW I suspect 99.999% of conditions won't have this problem, because
most clauses won't have this type of failures. And as demonstrated,
there are preexisting cases with similar behavior.

regards

--
Tomas Vondra