From: | peter plachta <pplachta(at)gmail(dot)com> |
---|---|
To: | "pgsql-performa(dot)" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Results of experiments with UUIDv7, UUIDv8 |
Date: | 2023-07-31 04:48:06 |
Message-ID: | CAGTqnmaRfR2a7Atk96Ey407bengt8mVXB6eHC7XDitzcfVHcpw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Hi all
My colleague and I did some experiments to see what effect using UUIDs as
2nd-ary indexes has on Index IO. The context is that by default ORM
frameworks will use UUIDs as index keys which I found as a major factor to
performance issues at Celonis. I suspect this isn't specific to Celonis.
The secondary factor is that random IO on Azure Single Server can be slow
as a dog -- thus for large enough indexes that aren't cached, and workloads
doing insert/delete at a high enough QPS, this really hurts.
We found that using UUID v7 (which has a longer time based prefix than v8)
gave 30% in IO savings in index access and roughly the same in index size
after I/D workload. v8 was ~24%. We simulated slow, random IO by running
this on a USB key which seemed to match Azure performance pretty well. SSD
was maybe 2x better.
This is relative to UUID v3 which is essentially random (actually, pretty
good random distribution on a 500Gb table).
This isn't as much as I expected, but, again for large indexes, slow IO, it
was significant.
peter
From | Date | Subject | |
---|---|---|---|
Next Message | peter plachta | 2023-07-31 05:00:15 | Table copy with SERIALIZABLE is incredibly slow |
Previous Message | Piyush Katariya | 2023-07-26 19:48:17 | Re: TOAST Fields serialisation/deserialization performance |