Re: Add PRODUCT() aggregate function - Mailing list pgsql-hackers

From Jeevan Chalke
Subject Re: Add PRODUCT() aggregate function
Date
Msg-id CAM2+6=Xp=FaW6rOCwNzWoxH7SjjEyw+ncyuoLr_+LuNEdEDLFA@mail.gmail.com
Whole thread
In response to Re: Add PRODUCT() aggregate function  (Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com>)
Responses Re: Add PRODUCT() aggregate function
List pgsql-hackers
Hello,

On Sun, Sep 13, 2026 at 12:23 PM Vaibhav Dalvi <vaibhav.dalvi@enterprisedb.com> wrote:
Hi Jeevan,

Thanks for the explanation and the pro() example, it is convincing.
I hadn't considered this properly earlier. for SUM the overflow
depends only on number of rows, but for PRODUCT it depends on the
values itself, so it will overflow in very few steps whenever values
are more than 1. So native fast path will help only for columns
having mostly 0, 1 or -1, not for large tables in general. I also
checked int128.h and you are right, there is no existing function
for overflow-checked "int128 *= int64" type of multiply, so this
needs new code, not reuse of the SUM(int8) pattern. So agree, fine to
take this up later as a follow-up, no need to block on it.

About your question on float8 vs numeric for float variants - I
would prefer float8. sum(float4)/sum(float8) already return
float4/float8, not numeric, so PRODUCT() staying same for float
types will be more consistent. It also avoids the overflow-primitive
problem for floats, since float just becomes Infinity instead of
erroring out. For int2/int4/int8 numeric is fine as it is.


Thanks Vaibhav (and Dean, Jim, back in June) for pushing on this -- agreed,
we'll switch product(float4)/product(float8) to return float8 natively rather
than numeric, consistent with sum(float4)/sum(float8).

Will post v3 with this change (float4/float8 -> float8) soon.

Thanks,
 
--
Jeevan Chalke
Senior Principal Engineer, Engineering Manager
Product Development


enterprisedb.com

pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: Teach pg_upgrade to deal with invalid databases
Next
From: Dmitry Dolgov
Date:
Subject: Re: System views for versions reporting