On Mon, Oct 2, 2017 at 8:07 PM, Alexander Korotkov <a.korotkov@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:
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.
BTW, you didn't comment Tom's suggestion about dropping high-order bit which trades minor user user confusion to minor loss of precision.
TBH, for me it's not so important whether we allow negative queryIds or drop high-order bit. I would be anyway very good to have 64-(or 63-)bit queryIds committed.