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
