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