On 25/05/2019 16:19, Peter Eisentraut wrote:
> On 2019-05-25 15:45, Ancoron Luciferis wrote:
>> So, my question now is: Would it make sense for you to handle these
>> time-based UUID's differently internally? Specifically un-shuffling the
>> timestamp before they are going to storage?
>
> It seems unlikely that we would do that, because that would break
> existing stored UUIDs, and we'd also need to figure out a way to store
> non-v1 UUIDs under this different scheme. The use case is pretty narrow
> compared to the enormous effort.
I agree, the backwards compatibility really would be a show stopper here.
About the "enormous effort" I was thinking the simplest "solution" would
be to have the version being detected at he time when the internal byte
array is created from the provided representation which then could
directly provide the unshuffled byte order.
>
> It is well understood that using UUIDs or other somewhat-random keys
> perform worse than serial-like keys.
Yes I know. We're using these UUID's for more than just some primary
key, because they also tell use the creation time of the entry and which
"node" of the highly distributed application generated the entry. It is
like an audit-log for us without the need for extra columns and of fixed
size, which helps performance also at the application level.
>
> Btw., it might be nice to rerun your tests with PostgreSQL 12beta1. The
> btree storage has gotten some improvements. I don't think it's going to
> fundamentally solve your problem, but it would be useful feedback.
>
Thank you for the pointer to 12beta1. I've just read about it and it
might help a bit. I'll give it a try, for sure and report back.
I also have to rerun those tests against PG 11 anyway.
Cheers,
Ancoron
