From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Ancoron Luciferis <ancoron.luciferis@googlemail.com>
To: pgsql-performance@lists.postgresql.org
Subject: Re: UUID v1 optimizations...
Date: Sat, 25 May 2019 16:19:59 +0200
Message-ID: <6099cb7d-3507-9b01-433d-dc709ecec8ed@2ndquadrant.com> (raw)
In-Reply-To: <8d5f4b67-d540-8d3d-9979-808b9c1e1ca7@googlemail.com>
References: <8d5f4b67-d540-8d3d-9979-808b9c1e1ca7@googlemail.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, ancoron.luciferis@googlemail.com, pgsql-performance@lists.postgresql.org
Subject: Re: UUID v1 optimizations...
In-Reply-To: <6099cb7d-3507-9b01-433d-dc709ecec8ed@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox