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
signature.asc
Description: PGP signature
