Or something like this in pseudocode: numeric = int8_numeric(*(uint64 *)(&i->data[0])) * int8_numeric(MAX_INT64) + int8_numeric(*(uint64 *)(&i->data[8]))
This is more like what I was hoping for, rather than converting to a string and back. Would you mind confirming for me: int8_numeric turns an int64 into an arbitrary-precision numeric Datum? So there is no overflow risk here?
But it looks like int8_numeric takes a *signed* integer. Isn't that a problem? I suppose I could get it working though by jumping through some hoops.
In UUID case you will take into account only half of value. Of course, GiST will work even with penalty function returning constant but each scan could become full-index-scan.
Yes, but that seems like an unrealistic concern. Even "only" 2^64 is 18446744073709551616 records. Or another way of thinking about it, if 64 bits (or 32) is a good enough penalty input for all the other data types, why not for UUIDs? Keep in mind type 3-5 UUIDs should be evenly distributed. Perhaps we could use the bottom half (instead of the top) to ensure even distribution for type 1 and 2 too.
It seems to me that using only the top half should be okay, but if you believe it's not I'll go with the int8_numeric approach (in three chunks instead of two to work around signed-vs-unsigned).
Thanks, Paul -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
