On 10/23/19 3:24 PM, Laiszner Tamás wrote:
That's an absolutely reasonable suggestion. I am still in the
exploration phase so while this solution is not completely ruled out,
I have some concerns about it:
1.
Although it does not enforce, but the UUID type kind of suggests a
specific interpretation of the data. Of course the documentation
says you are free to use any algorithm to generate the values, but
there are quite a few standard UUID types and we are not planning
to use any of them.
2.
The serialization format is different than needed by the
application and, while once again this is not a hard technical
barrier, that might cause slight additional complexity and confusion.
3.
The value is logically defined as a 128-bit integer, that is in
itself a compound value split into a few "bit groups". Extracting
these parts can be done by simple (and supposedly efficient)
bitwise operators when stored as integer, but becomes much more
cumbersome with UUID, I guess.
------------------------------------------------------------------------
*Feladó:* Rob Sargent <robjsarg...@gmail.com>
*Elküldve:* 2019. október 23., szerda 22:58
*Címzett:* Laiszner Tamás <t.laisz...@outlook.com>
*Másolatot kap:* pgsql-gene...@postgresql.org
<pgsql-gene...@postgresql.org>
*Tárgy:* Re: Composite type storage overhead
On Oct 23, 2019, at 1:32 PM, Laiszner Tamás <t.laisz...@outlook.com
<mailto:t.laisz...@outlook.com>> wrote:
Hey there,
I am currently exploring the options to utilize 128-bit numeric
primary keys. One of the options I am looking at is to store them as
composites of two 64-bit integers.
I would highly appreciate any comments or additional information on
this topic.
Best regards,
Tamas
Why not use UUID type?
Putting logic and meaning into primary keys? To what end, I wonder.
