Re: SUM(int2)/SUM(int4) do not detect overflow of the int8 accumulator

On Fri, Sep 04, 2026 at 08:55:07PM +1200, David Rowley wrote:
> Since Andrei has demonstrated that it's possible to hit that limit
> with a non-parallel query in less than 5 minutes, albeit that is
> passing INT_MAX (the most extreme case), it might be worth adding the
> checks. I was surprised that it only took 5 mins to do 4 billion rows,
> especially with generate_series. It's probably just a matter of time
> before someone discovers this with a real-world case out in the wild.

I guess so..

> If there's a measurable performance regression from adding the
> overflow checks, does the attached buy enough of it back? I couldn't
> really measure much of a performance difference from it on my Zen2
> machine, so I didn't try with the overflow patch.
>
> The patch adds PG_RETURN_INPUT(n) to avoid some of the branching in
> int4_sum() so that it immediately returns the aggstate when the value
> being aggregated is null. With my compiler, it cut int4_sum from 18
> down to 16 instructions.

FWIW, I've always been a fan of your compiler magic tricks like this
one. Even if you did not measure much of a performance difference at
runtime, less instructions overall across gcc and clang sounds like a
better deal to me anyway? It sounds like the sort of improvements
that could be done independently of what is being discussed here.
--
Michael