From: | Paul Jungwirth <pj(at)illuminatedcomputing(dot)com> |
---|---|
To: | Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Review: GiST support for UUIDs |
Date: | 2015-09-14 23:18:39 |
Message-ID: | 55F755CF.1000900@illuminatedcomputing.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Haribabu Kommi | 2015-09-15 00:38:55 | Re: Multi-tenancy with RLS |
Previous Message | David Rowley | 2015-09-14 23:13:49 | Re: WIP: Make timestamptz_out less slow. |