From: Ancoron Luciferis <ancoron.luciferis@googlemail.com>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: pgsql-performance@lists.postgresql.org
Subject: Re: UUID v1 optimizations...
Date: Sat, 25 May 2019 19:27:21 +0200
Message-ID: <cdca815e-cde8-cb0f-b0e4-4e19e1e83d51@googlemail.com> (raw)
In-Reply-To: <6099cb7d-3507-9b01-433d-dc709ecec8ed@2ndquadrant.com>
References: <8d5f4b67-d540-8d3d-9979-808b9c1e1ca7@googlemail.com>
<6099cb7d-3507-9b01-433d-dc709ecec8ed@2ndquadrant.com>
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
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: ancoron.luciferis@googlemail.com, peter.eisentraut@2ndquadrant.com, pgsql-performance@lists.postgresql.org
Subject: Re: UUID v1 optimizations...
In-Reply-To: <cdca815e-cde8-cb0f-b0e4-4e19e1e83d51@googlemail.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