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
-- Adrian Klaver adrian.klaver@xxxxxxxxxxx
