On Tue, Apr 7, 2026 at 12:32 AM Zsolt Parragi <zsolt.parragi@percona.com> wrote:
>
> > Its intentionally uint64, per this comment above it:
> >
> > * Note we utilize unsigned integers even though ticks are stored as a signed
> > * value to encourage compilers to generate better assembly, since we can be
> > * sure these values are not negative.
> >
> > In my earlier Compiler Explorer tests that did actually make a
> > difference for the generated assembly.
>
> Isn't that comment more about ticks_per_ns_scaled?
>
> For max_ticks_no_overflow the only use is with a cast to int64, so I
> didn't expect much assembly difference. Now I actually checked
> locally/godbolt, and I don't see any actual differences. Making
> max_ticks_no_overflow int64 and removing that cast generates exactly
> the same code.
>
> For ticks_per_ns_scaled, gcc 9-10 actually generates +1 mov
> instruction with int64, but that's not present in more recent
> versions.
>
> Recent compiler versions only have an idiv/div and shr/sar difference.
> Idiv is slower than div on intel, so that is a point for keeping
> ticks_per_ns_scaled unsigned.
>
> For arm I see the same lsr/asr and udiv/sdiv difference.
>
> https://godbolt.org/z/4r5GTbrs3
>
> (the main gcc vs clang difference seems to be clang's 32 bit division
> optimization)
Thanks for re-checking, and I think you're correct in your assessment
that max_ticks_no_overflow could be signed. But I also don't think it
does any harm for it to be unsigned, since we know it will never be
negative, and we're correctly using PG_INT64_MAX when initializing it
(i.e. we use the max that's valid for ticks, which is int64).
I don't feel strongly about this. I'll let Andres make the call
whether its worth changing.
Thanks,
Lukas
--
Lukas Fittl
