Re: Sequence vs UUID

From: veem v <veema0000(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Dominique Devienne <ddevienne(at)gmail(dot)com>, Miles Elam <miles(dot)elam(at)productops(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org
Subject: Re: Sequence vs UUID
Date: 2023-01-30 19:43:00
Message-ID: CAB+=1TXiLmd4hGvmWZCz7fFjWDkG92i=+80G42m5-wPa_mCLYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

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?

On Mon, 30 Jan 2023 at 22:18, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> > On Mon, Jan 30, 2023 at 5:11 PM veem v <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
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2023-01-30 19:46:23 Re: Sequence vs UUID
Previous Message Alvaro Herrera 2023-01-30 17:44:37 Re: How could I elog the tupleTableSlot to the fronted terminal?