Re: BUG #17961: Incorrect aggregation MIN, AVG, MAX - Mailing list pgsql-bugs

From Maxim Zakharov
Subject Re: BUG #17961: Incorrect aggregation MIN, AVG, MAX
Date
Msg-id CAFWuPyoWjdeP5z4tw+UpCtDrTfvBym7a-CzgzxhbKGYa7fzzaw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17961: Incorrect aggregation MIN, AVG, MAX  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-bugs
Hello,

You're right, the SQL query was incorrect. Shame on me! :]

Thank you and sorry for bothering with such a mistake.

On Mon, 5 Jun 2023 at 17:40, Julien Rouhaud <rjuju123@gmail.com> wrote:
Hi,

On Sun, Jun 04, 2023 at 10:04:04PM +0000, PG Bug reporting form wrote:
>
> I came across a situation when MIN(), AVG() and MAX() aggregates where
> computed incorrectly, as you can see from the output below the valuer of
> MIN() is higher than AVG() and MAX()!
> Expected values should be the same as for MIN()
> The table n has all values been updated several times with different values
> and currently all rows contain the value of 11.55
>
> asx=# select at, MIN(diluted_earnings_1)::numeric as diluted_earnings_1min,
> ROUND(AVG(diluted_earnings)::numeric, 2) as diluted_earnings_1avg,
> MAX(diluted_earnings)::numeric as diluted_earnings_1max

Unless I'm missing something you're using diluted_earnings_1 for min, but
diluted_earnings for avg and max so it looks like it's working as expected?


--

pgsql-bugs by date:

Previous
From: Julien Rouhaud
Date:
Subject: Re: BUG #17961: Incorrect aggregation MIN, AVG, MAX
Next
From: Alexander Lakhin
Date:
Subject: Re: BUG #17959: amcheck fails to find a matching index tuple for an invisible heap tuple