Re: Composite type storage overhead

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 <robjsargent(at)gmail(dot)com>
> *Elküldve:* 2019. október 23., szerda 22:58
> *Címzett:* Laiszner Tamás <t(dot)laiszner(at)outlook(dot)com>
> *Másolatot kap:* pgsql-general(at)postgresql(dot)org
> <pgsql-general(at)postgresql(dot)org>
> *Tárgy:* Re: Composite type storage overhead
>
>
>> On Oct 23, 2019, at 1:32 PM, Laiszner Tamás <t(dot)laiszner(at)outlook(dot)com
>> <mailto:t(dot)laiszner(at)outlook(dot)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.