Re: Sequence vs UUID

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(at)sss(dot)pgh(dot)pa(dot)us
> <mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us>> wrote:
>
> Dominique Devienne <ddevienne(at)gmail(dot)com
> <mailto:ddevienne(at)gmail(dot)com>> writes:
> > On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000(at)gmail(dot)com
> <mailto:veema0000(at)gmail(dot)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
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com