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@gmail.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