On 9/18/26 01:58, Richard Guo wrote:
> On Fri, Sep 18, 2026 at 12:55 AM Robert Haas <[email protected]> wrote:
>> On Thu, Sep 17, 2026 at 10:58 AM Richard Guo <[email protected]> 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
