On Mon, Oct 2, 2017 at 8:07 PM, Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > +1, > I see 3 options there: > 1) Drop high-order bit, as you proposed. > 2) Allow negative queryIds. > 3) Implement unsigned 64-type. > > #1 causes minor loss of precision which looks rather insignificant in given > context. > #2 might be rather unexpected for users whose previously had non-negative > queryIds. Changing queryId from 32-bit to 64-bit itself might require some > adoption from monitoring software. But queryIds are user-visible, and > negative queryIds would look rather nonlogical. > #3 would be attaching hard and long-term problem by insufficient reason. > Thus, #1 looks like most harmless solution.
I think we should just allow negative queryIds. I mean, the hash functions have behaved that way for a long time: rhaas=# select hashtext(''); hashtext ------------- -1477818771 (1 row) It seems silly to me to throw away a perfectly good bit from the hash value just because of some risk of minor user confusion. I do like Michael's suggestion of outputing hexa-like text, but changing the types of the user-visible output columns seems like a job for another patch. Similarly, if we were to adopt Andres's suggestions of a new type or using numeric or Alexander's suggestion of implementing a 64-bit unsigned type, I think it should be a separate patch from this one. I would note that such a patch will actually create real incompatibility -- extension upgrades might fail if there are dependent views, for example -- whereas merely having query IDs start to sometimes be negative only creates an incompatibility for people who assumed that the int64 type wouldn't actually use its full range of allowable values. I don't deny that someone may have done that, of course, but I wouldn't guess that it's a common thing... maybe I'm wrong. Meanwhile, updated patch with a fix for the typo pointed out by Vladimir Sitnikov attached. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
64-bit-queryid-v2.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers