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@xxxxxxxxxxxxx
<mailto:tgl@xxxxxxxxxxxxx>> wrote:
Dominique Devienne <ddevienne@xxxxxxxxx
<mailto:ddevienne@xxxxxxxxx>> writes:
> On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000@xxxxxxxxx
<mailto:veema0000@xxxxxxxxx>> 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.
