From: | Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au> |
---|---|
To: | "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru> |
Cc: | Peter Eisentraut <peter(at)eisentraut(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Przemysław Sztoch <przemyslaw(at)sztoch(dot)pl>, Michael Paquier <michael(at)paquier(dot)xyz>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers mailing list <pgsql-hackers(at)postgresql(dot)org>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Mat Arye <mat(at)timescaledb(dot)com>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Nikolay Samokhvalov <samokhvalov(at)gmail(dot)com>, Junwang Zhao <zhjwpku(at)gmail(dot)com>, Stepan Neretin <sncfmgg(at)gmail(dot)com> |
Subject: | Отв.: Re: UUID v7 |
Date: | 2024-11-29 04:13:52 |
Message-ID: | 479269655.3354148.1732853632177@mail.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I mean to add not benchmark results to the patch, but functions so that everyone can compare themselves on their equipment. The comparison with UUIDv4 is not very interesting, as the choice is usually between UUIDv7 and an integer key. And I have described many use cases, and in your benchmark there is only one, the simplest.
Отправлено из Yahoo Почты на iPhone
Пользователь четверг, ноября 28, 2024, 11:09 AM написал Andrey M. Borodin <x4mmm(at)yandex-team(dot)ru>:
> On 28 Nov 2024, at 04:07, Sergey Prokhorenko <sergeyprokhorenko(at)yahoo(dot)com(dot)au> wrote:
>
> It would be useful to add a standard comparative benchmark with several parameters and use cases to the patch, so that IT departments can compare UUIDv7, ULID, UUIDv4, Snowflake ID and BIGSERIAL for their hardware and conditions.
>
> I know for a fact that IT departments make such benchmarks of low quality. They usually measure the generation rate, which is meaningless because it is usually excessive. It makes sense to measure the rate of single-threaded and multi-threaded insertion of a large number of records (with and without partitioning), as well as the rate of execution of queries to join big tables, to update or delete a large number of records. It is important to measure memory usage, processor load, etc.
Publishing benchmarks seems to be far beyond what our documentation go for. Mostly, because benchmarks are tricky. You can prove anything with benchmarks.
Everyone is welcome to publish benchmark results in their blogs, but IMO docs have a very different job to do.
I’ll just publish one benchmark in this mailing list. With patch v39 applied on my MB Air M2 I get:
postgres=# create table table_for_uuidv4(id uuid primary key);
CREATE TABLE
Time: 9.479 ms
postgres=# insert into table_for_uuidv4 select uuidv4() from generate_series(1,3e7);
INSERT 0 30000000
Time: 2003918.770 ms (33:23.919)
postgres=# create table table_for_uuidv7(id uuid primary key);
CREATE TABLE
Time: 3.930 ms
postgres=# insert into table_for_uuidv7 select uuidv7() from generate_series(1,3e7);
INSERT 0 30000000
Time: 337001.315 ms (05:37.001)
Almost an order of magnitude better :)
Best regards, Andrey Borodin.
From | Date | Subject | |
---|---|---|---|
Next Message | Kirill Reshke | 2024-11-29 04:22:47 | Re: Отв.: Re: UUID v7 |
Previous Message | Kirill Reshke | 2024-11-29 03:55:03 | Re: Using read stream in autoprewarm |