Re: Add comment explaining why queryid is int64 in pg_stat_statements

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Lukas Fittl <lukas(at)fittl(dot)com>, David Rowley <dgrowleyml(at)gmail(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Shaik Mohammad Mujeeb <mujeeb(dot)sk(at)zohocorp(dot)com>, ilyaevdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, mujeebskdev <mujeeb(dot)sk(dot)dev(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add comment explaining why queryid is int64 in pg_stat_statements
Date: 2025-05-20 06:12:13
Message-ID: aCwdPY8WF36MjjEz@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, May 20, 2025 at 02:09:13PM +0900, Michael Paquier wrote:
> On Mon, May 19, 2025 at 08:43:25PM -0700, Lukas Fittl wrote:
> > Yeah, +1 to making this consistent across both query ID and the new plan
> > ID, and changing both to int64 internally seems best.
>
> Any thoughts from others? I'm OK to take the extra step of switching
> both fields on HEAD and write a patch for that, relying on what David
> has sent as a first step towards that.

I don't think it was discussed, but why not go the other way, keep everything
as uint64 and expose an uint64 datatype at the SQL level instead? That's
something I actually want pretty often so I would be happy to have that
natively, whether it's called bigoid, oid8 or anything else. That's probably
too late for pg18 though.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2025-05-20 06:27:30 Re: [PATCH] Allow parallelism for plpgsql return expression after commit 556f7b7
Previous Message David Rowley 2025-05-20 05:51:51 Re: Add comment explaining why queryid is int64 in pg_stat_statements