| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Ancoron Luciferis <ancoron(dot)luciferis(at)googlemail(dot)com>, pgsql-performance(at)lists(dot)postgresql(dot)org |
| Subject: | Re: UUID v1 optimizations... |
| Date: | 2019-05-25 14:19:59 |
| Message-ID: | 6099cb7d-3507-9b01-433d-dc709ecec8ed@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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.
It is well understood that using UUIDs or other somewhat-random keys
perform worse than serial-like keys.
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.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-05-25 14:57:50 | Re: UUID v1 optimizations... |
| Previous Message | Ancoron Luciferis | 2019-05-25 13:45:53 | UUID v1 optimizations... |