Thread

Re: Add comment explaining why queryid is int64 in pg_stat_statements

Julien Rouhaud <rjuju123@gmail.com> — 2025-05-21T12:19:56Z

On Wed, May 21, 2025 at 09:34:02AM +0900, Michael Paquier wrote:
> On Tue, May 20, 2025 at 11:28:17PM +1200, David Rowley wrote:
> > Certainly, a bit late, yes. It basically requires implementing
> > unsigned types on the SQL level. I believe there are a few sunken
> > ships along that coastline, and plenty of history in the archives if
> > you want to understand some of the difficulties.
>
> Providing some more context and some more information than this reply,
> the latest thread that I can find on the matter is this one, from
> December 2024:
> https://www.postgresql.org/message-id/CAN3gO4sPBKbfWYK10i294u3kzsfDb4WX891FMbjLnKjMS08u7A%40mail.gmail.com
>
> It summarizes nicely the situation and it contains some more general
> points.
>
> This particular point from Tom about numeric promotion and casting
> hierarchy resonates as a very good one:
> https://www.postgresql.org/message-id/3180774.1733588677%40sss.pgh.pa.us
> My own bet is that if you don't want to lose any existing
> functionality, perhaps we should be just more aggressive with casting
> requirements on input to begin with even if it means more work when
> writing queries, even if it comes at a loss of usability that should
> still be something..

Thanks a lot Michael!  I actually read that thread at that time but forgot
about it until you sent this link.

> FWIW, I've wanted an unsigned in-core type more than once.  It would
> be a lot of work, but we have a lot of things that exist in the core
> code that map to unsigned 32b or 64b integer values.  Just naming one,
> WAL LSN difference calculations.  XLogRecPtr is a 64b unsigned value,
> not its representation at SQL level, meaning that we'd overflow after
> reaching the threshold of the bit tracking the signedness.  It's true
> that a system would need to live long enough to reach such LSNs, but
> we have also 32b integers plugged here and there.  Another one is
> block numbers, or OID which is an in-core type.  Having an in-core
> unsigned integer type would scale better that creating types mapping
> to every single internal core concept.

Agreed.