On 2017-10-03 03:07:09 +0300, Alexander Korotkov wrote: > On Tue, Oct 3, 2017 at 12:32 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > Peter Geoghegan <p...@bowt.ie> writes: > > > You need to change the SQL interface as well, although I'm not sure > > > exactly how. The problem is that you are now passing a uint64 queryId > > > to Int64GetDatumFast() within pg_stat_statements_internal(). That > > > worked when queryId was a uint32, because you can easily represent > > > values <= UINT_MAX as an int64/int8. However, you cannot represent the > > > second half of the range of uint64 within a int64/int8. I think that > > > this will behave different depending on USE_FLOAT8_BYVAL, if nothing > > > else. > > > > Maybe intentionally drop the high-order bit, so that it's a 63-bit ID? > > > > +1, > I see 3 options there: > 1) Drop high-order bit, as you proposed. > 2) Allow negative queryIds. > 3) Implement unsigned 64-type.
4) use numeric, efficiency when querying is not a significant concern here 5) use a custom type that doesn't support arithmetic, similar to pg_lsn. FWIW, I think we should consider going for something like 5) for pg_class.relpages. - Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
