Re: Sequence vs UUID

And populate that column with UUIDs generated by the gen_random_uuid() function.

(Requires v13.)

On 1/30/23 13:46, Adrian Klaver wrote:
> On 1/30/23 11:43, veem v wrote:
>> Thank You So much for the details. I am a bit new to postgres. And these 
>> test results I picked were from a dev system. If I understand it 
>> correctly, do you mean these settings(usage of C locale or "native" 
>> 16-byte uuid) which you mentioned should be there in a production system 
>>   and thus we should test the performance of the UUID vs sequence on a 
>> similar setup? Or say if this sort of degradation of UUID performance is 
>> not expected then , how to get these settings tweaked ON, so as to see 
>> the best string type or UUID performance, can you please guide me here?
>
> No what is being said is change:
>
> source_id varchar(36)
>
> to
>
> source_id uuid
>
> as i:
>
> https://www.postgresql.org/docs/current/datatype-uuid.html
>
>>
>> On Mon, 30 Jan 2023 at 22:18, Tom Lane <tgl@sss.pgh.pa.us 
>> <mailto:tgl@sss.pgh.pa.us>> wrote:
>>
>>     Dominique Devienne <ddevienne@gmail.com
>>     <mailto:ddevienne@gmail.com>> writes:
>>      > On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000@gmail.com
>>     <mailto:veema0000@gmail.com>> wrote:
>>      >> CREATE TABLE test1_UUID ( id bigint,source_id varchar(36)
>>     PRIMARY KEY, Name varchar(20) );
>>
>>      > Maybe if you used a "native" 16-byte uuid, instead of its textual
>>      > serialization with dashes (36 bytes + length overhead), the gap would
>>      > narrow.
>>
>>     Yeah, especially if your database is not using C locale. The
>>     strcoll or ICU-based comparisons done on string types can be
>>     enormously more expensive than the memcmp() used for binary
>>     types like native uuid.
>>
>>                              regards, tom lane
>>
>

-- 
Born in Arizona, moved to Babylonia.