Re: libuuid performance impact

Hi

I've been investigating a performance "problem" with uuid generation
https://jasonaowen.net/blog/2017/Apr/13/benchmarking-uuids-v2/, which I
couldn't reproduce on my computer while it occurred on my servers. After
a few tests, it seems to come from uuid-ossp being replaced with
libuuid… when linking postgresql with uuid-ossp I get the exact same
performance between uuid_generate_v4 and gen_random_uuid. When linking
with libuuid, I get the same results as those displayed in the linked
webpage (I can provide numbers).

Is this an expected difference ?

Please tell me what I can provide if required.

Regards

Marc

Re: Marc Cousin 2018-04-30 <4f125945-e979-1f9e-a39b-a4bf5a4eca6b(at)gmail(dot)com>
> Hi
>
> I've been investigating a performance "problem" with uuid generation
> https://jasonaowen.net/blog/2017/Apr/13/benchmarking-uuids-v2/, which I
> couldn't reproduce on my computer while it occurred on my servers. After
> a few tests, it seems to come from uuid-ossp being replaced with
> libuuid… when linking postgresql with uuid-ossp I get the exact same
> performance between uuid_generate_v4 and gen_random_uuid. When linking
> with libuuid, I get the same results as those displayed in the linked
> webpage (I can provide numbers).
>
> Is this an expected difference ?

It also depends which uuid "version" you are generating"

=# explain analyze select uuid_generate_v1() from generate_series(1, 1000000);
Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=16) (actual time=129.701..6847.020 rows=1000000 loops=1)
Planning time: 0.071 ms
Execution time: 6921.871 ms

=# explain analyze select uuid_generate_v4() from generate_series(1, 1000000);
Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=16) (actual time=123.784..5164.752 rows=1000000 loops=1)
Planning time: 0.073 ms
Execution time: 5203.226 ms

=# explain analyze select gen_random_uuid() from generate_series(1, 1000000); QUERY PLAN
Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=16) (actual time=121.428..1908.190 rows=1000000 loops=1)
Planning time: 0.070 ms
Execution time: 1947.951 ms

I can't say if this is expected, or if the libuuid performance is just
worse, or if maybe the libuuid UUIDs are generated using stronger
crypto.

Is that performance difference a problem for you in practise?

Christoph

First, sorry for the delay, I've been out of office for a few days.

On 01/05/2018 16:24, Christoph Berg wrote:
> Re: Marc Cousin 2018-04-30 <4f125945-e979-1f9e-a39b-a4bf5a4eca6b(at)gmail(dot)com>
>> Hi
>>
>> I've been investigating a performance "problem" with uuid generation
>> https://jasonaowen.net/blog/2017/Apr/13/benchmarking-uuids-v2/, which I
>> couldn't reproduce on my computer while it occurred on my servers. After
>> a few tests, it seems to come from uuid-ossp being replaced with
>> libuuid… when linking postgresql with uuid-ossp I get the exact same
>> performance between uuid_generate_v4 and gen_random_uuid. When linking
>> with libuuid, I get the same results as those displayed in the linked
>> webpage (I can provide numbers).
>>
>> Is this an expected difference ?
> It also depends which uuid "version" you are generating"
Yes, that's right, as the uuid doesn't use the same kind of data source
depending on the version. gen_random_uuid produces a V4 uuid.

>
> =# explain analyze select uuid_generate_v1() from generate_series(1, 1000000);
> Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=16) (actual time=129.701..6847.020 rows=1000000 loops=1)
> Planning time: 0.071 ms
> Execution time: 6921.871 ms
>
> =# explain analyze select uuid_generate_v4() from generate_series(1, 1000000);
> Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=16) (actual time=123.784..5164.752 rows=1000000 loops=1)
> Planning time: 0.073 ms
> Execution time: 5203.226 ms
>
> =# explain analyze select gen_random_uuid() from generate_series(1, 1000000); QUERY PLAN
> Function Scan on generate_series (cost=0.00..12.50 rows=1000 width=16) (actual time=121.428..1908.190 rows=1000000 loops=1)
> Planning time: 0.070 ms
> Execution time: 1947.951 ms
>
> I can't say if this is expected, or if the libuuid performance is just
> worse, or if maybe the libuuid UUIDs are generated using stronger
> crypto.
>
> Is that performance difference a problem for you in practise?
It's not a big problem for us yet, as on most of our applications, the
UUID generation doesn't amount for a big part of the costs.

But we are building an audit application, and uuid will probably become
non-negligible there. That's where the benchmark comes from :)

So there is no emergency for us (we would have rebuilt the package
ourselves or used the pgcrypto version if that was the case), but after
diagnosing this I thought it was an issue that should be brought to your
attention.

Regards,

Marc