Thread: Sequence vs UUID

> On Jan 26, 2023, at 11:17, veem v <veema0000@gmail.com> wrote:
> So we want to understand from experts here, if there are any clear rules available or if we have any pros vs cons
listavailable for each of those to understand the exact scenario in which we should go for one over other? 

Clear rules are a bit difficult to come by here, but there are general guidelines.

First, the distinction isn't exactly UUIDs vs sequences.  There are two distinctions:

1. UUIDs vs bigints.
2. Sequential values vs random values.

The advantage of bigints vs UUIDs is that bigints will faster for PostgreSQL to process in a variety of ways, as well
asbeing half the size of a UUID (so, smaller tables, smaller indexes, etc.).  The main advantage of UUIDs vs bigints
is,if you are using random values, there's existing easy-to-use infrastructure for generating UUIDs vs generating
randombigints. 

The advantage of sequential values is that they interact much better with caching than random values.  Random values
willhave a harder time maintaining a reasonable in-memory working set than sequential values.  (Of course, if the
databasefits entirely in memory, this isn't as much of an issue).  The advantage of random values is that they are more
opaque;if there is a 123480102 in a sequential key, an attacker can be confident there's also a 123480103, which a
randomvalue avoids.  There are algorithms for generating sequential values that avoid this by having hard-to-guess less
significantdigits. 

Another advantage of sequential values is that they are (roughly) time-ordered, so they can be used to get "most
recent"efficiently. 

One concern about sequential values that generally is not a real issue is the bottleneck of creating new sequential
values. The sequence functionality in PostgreSQL is very concurrency-friendly. 

UUIDs can be generated in such a way that they have sequential properties; see:

    https://github.com/tvondra/sequential-uuids

On Thu, Jan 26, 2023 at 1:18 PM veem v <veema0000@gmail.com> wrote:

Hello, We were trying to understand whether we should use UUID or Sequence in general for primary keys. In many of the blogs(one is below) across multiple databases, I saw over the internet and all are mostly stating the sequence is better as compared to UUID. But I think in the case of concurrent data load scenarios UUID will spread the contention point whereas sequence can be a single point of contention. 

So we want to understand from experts here, if there are any clear rules available or if we have any pros vs cons list available for each of those to understand the exact scenario in which we should go for one over other? Basically I wanted to see if we can perform some test on sample data to see the percentage of overhead on read and write performances of the query in presence of UUID VS Sequence to draw some conclusion in general? And also considering open source postgres as the base for many databases like redshift etc, so the results which apply to progress would apply to others as well.

https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/

* UUIDs are big for identifer (16 bytes) sequence is 4 or 8

* sequences are NOT a contention point, database uses some tricks to work around that
* UUIDS are basically random data causing page fragmentation.  this is particularly bad in auto clustering architectures like sql server 

* Also, UUIDS can deliver very poor buffer hit ratios when sweeping ranges of records on large tables.   

merlin

 

> On 26/01/2023 20:17 CET veem v <veema0000@gmail.com> wrote:
>
> Hello, We were trying to understand whether we should use UUID or Sequence in
> general for primary keys. In many of the blogs (one is below) across multiple
> databases, I saw over the internet and all are mostly stating the sequence is
> better as compared to UUID. But I think in the case of concurrent data load
> scenarios UUID will spread the contention point whereas sequence can be a
> single point of contention.
>
> So we want to understand from experts here, if there are any clear rules
> available or if we have any pros vs cons list available for each of those to
> understand the exact scenario in which we should go for one over other?
> Basically I wanted to see if we can perform some test on sample data to see
> the percentage of overhead on read and write performances of the query in
> presence of UUID VS Sequence to draw some conclusion in general? And also
> considering open source postgres as the base for many databases like redshift
> etc, so the results which apply to progress would apply to others as well.
>
> https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/

I think that[1] provides a good summary.  Performance consideration is just one
aspect.  Is there a technical requirement for using UUID over sequential values?

If there's a single generator of primary keys use bigint sequences.  In case of
multiple generators (multi-master replication, sharding, clients generating IDs)
consider UUID.

There are arguments against sequential PK, e.g. they give away too much info and
allow attacks such as forced browsing[2].  The first I can understand: you may
not want to reveal the number of users or customers.  But access control should
prevent forced browsing.

[1] https://www.cybertec-postgresql.com/en/uuid-serial-or-identity-columns-for-postgresql-auto-generated-primary-keys/
[2] https://owasp.org/www-community/attacks/Forced_browsing

--
Erik

On 1/26/23 15:55, Erik Wienhold wrote:
>> On 26/01/2023 20:17 CET veem v <veema0000@gmail.com> wrote:
>>
>> Hello, We were trying to understand whether we should use UUID or Sequence in
>> general for primary keys. In many of the blogs (one is below) across multiple
>> databases, I saw over the internet and all are mostly stating the sequence is
>> better as compared to UUID. But I think in the case of concurrent data load
>> scenarios UUID will spread the contention point whereas sequence can be a
>> single point of contention.
>>
>> So we want to understand from experts here, if there are any clear rules
>> available or if we have any pros vs cons list available for each of those to
>> understand the exact scenario in which we should go for one over other?
>> Basically I wanted to see if we can perform some test on sample data to see
>> the percentage of overhead on read and write performances of the query in
>> presence of UUID VS Sequence to draw some conclusion in general? And also
>> considering open source postgres as the base for many databases like redshift
>> etc, so the results which apply to progress would apply to others as well.
>>
>> https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/
> I think that[1] provides a good summary.  Performance consideration is just one
> aspect.  Is there a technical requirement for using UUID over sequential values?
>
> If there's a single generator of primary keys use bigint sequences.  In case of
> multiple generators (multi-master replication, sharding, clients generating IDs)
> consider UUID.
>
> There are arguments against sequential PK, e.g. they give away too much info and
> allow attacks such as forced browsing[2].  The first I can understand: you may
> not want to reveal the number of users or customers.  But access control should
> prevent forced browsing.

Shouldn't your application layer isolate the users from the database?  UUIDs 
are all over the DBs I manage, but the PKs are all sequences.

-- 
Born in Arizona, moved to Babylonia.

Hello.

I have been using UUID for quite a long time now. The reason I began to use UUID was the need to be able to move data
between
databases and the need to create record outside the database. You should use UUID as a primary key for a record and
alsohave
 
some bookkeeping UUID:s in the record like "origin" of the record. In this way it is "easy" to handle different sources
of
data.

We have also written some nice replicating software on this basis (postsync) that can check for alterations in one
database
and update others. In this way we can keep one or many replicas of databases.

So forget about performance issues (there will ALWAYS be need for faster systems). The ease and functionality with
UUID
is so mutch better. Sequence keys are a terrible idea!

// GH


Den 2023-01-26 kl. 20:17, skrev veem v:
> Hello, We were trying to understand whether we should use UUID or Sequence in general for primary keys. In many of
theblogs(one is below) across multiple databases, I saw over the internet and all are mostly stating the sequence is
betteras compared to UUID. But I think in the case of concurrent data load scenarios UUID will spread the contention
pointwhereas sequence can be a single point of contention.
 
> 
> So we want to understand from experts here, if there are anyclear rules available or if we haveany pros vs cons list
availablefor each of those to understand the exact scenario in which we should go for one over other? Basically I
wantedtosee if we can perform some test on sample data to see the percentage of overhead on read and write performances
ofthe query in presence of UUID VS Sequence to draw some conclusion in general? And also considering open source
postgres asthe base for many databases like redshift etc, so the results which apply to progress would apply to others
aswell.
 
> 
> https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/
<https://www.percona.com/blog/2019/11/22/uuids-are-popular-but-bad-for-performance-lets-discuss/>
> 

-- 
gorhas@raditex.nu
http://www.raditex.nu
Raditex Control AB
Bo 229, 715 91 ODENSBACKEN
Mob: 070-5530148

> So forget about performance issues (there will ALWAYS be need for faster systems). The ease and functionality with
UUID
> is so mutch better. Sequence keys are a terrible idea!
>
> // GH
>
Wow. I am not alone
>

> On 27/01/2023 01:48 CET Ron <ronljohnsonjr@gmail.com> wrote:
>
> On 1/26/23 15:55, Erik Wienhold wrote:
> >
> > There are arguments against sequential PK, e.g. they give away too much info and
> > allow attacks such as forced browsing[2].  The first I can understand: you may
> > not want to reveal the number of users or customers.  But access control should
> > prevent forced browsing.
>
> Shouldn't your application layer isolate the users from the database?  UUIDs
> are all over the DBs I manage, but the PKs are all sequences.

Yes, I meant the application layer, not Postgres' access control.

--
Erik

Why is it a terrible idea? I have been using them for years without a single problem. I don't rely on them for create order. Terrible seem a bit extreme.

Thanks,

Ben

On Sat, Jan 28, 2023, 3:39 PM Erik Wienhold <ewie@ewie.name> wrote:

> On 27/01/2023 01:48 CET Ron <ronljohnsonjr@gmail.com> wrote:
>
> On 1/26/23 15:55, Erik Wienhold wrote:
> >
> > There are arguments against sequential PK, e.g. they give away too much info and
> > allow attacks such as forced browsing[2].  The first I can understand: you may
> > not want to reveal the number of users or customers.  But access control should
> > prevent forced browsing.
>
> Shouldn't your application layer isolate the users from the database?  UUIDs
> are all over the DBs I manage, but the PKs are all sequences.

Yes, I meant the application layer, not Postgres' access control.

--
Erik

On Sat, Jan 28, 2023 at 6:02 PM Ron <ronljohnsonjr@gmail.com> wrote:
>
> Type 4 UUIDs are sub-optimal for big table because cache hit rates drop through the floor.
>
> This lesson was burned into my psyche waaaay back in the Clinton administration.  It was my task to speed up a five
hourbatch job which read input records from a flat file, did some validations and then inserted them.  Simply sorting
theinput file on the primary key fields -- we used natural keys, not synthetics -- dropped the run time to two hours.
(VMSSORT saved the day, because you could tell it the sort order you wanted; thus, I could preserve the header record
atthe top of the file, and the trailer record at the end of the file without jumping through a bunch of hoops.) 

This can be mitigated with judicious use of a sequence at the front of
the uuidv4.

    https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/

More effort than just calling the built-in gen_random_uuid() or
equivalent in app code, but a substantial performance gain for your
effort.

    https://github.com/tvondra/sequential-uuids

And in a managed environment where you can't install custom
extensions, a fairly simple function with divide on unix epoch seconds
combined with a call to overlay(...) should suffice performance-wise.
At 60 seconds, this will loop every 45 days or so, and you can choose
how much "sequentialness" works for you, from 1 to 4 bytes at the
expense of pseudo-randomness.

-----------------------------

-- Generate time interval UUID
CREATE OR REPLACE FUNCTION gen_interval_uuid(interval_seconds int4 =
60, block_num_bytes int2 = 2)
RETURNS uuid LANGUAGE sql VOLATILE PARALLEL SAFE AS $$
  SELECT encode(
    overlay(
      -- convert the uuid to byte array
      uuid_send(gen_random_uuid())
      -- use only the bottom bytes
      PLACING substring(
          int4send((extract(epoch FROM now()) / interval_seconds)::int4)
          FROM (5 - block_num_bytes)
      )
      -- place at the front two bytes of the uuid
      FROM 1
    )
    -- convert the resulting byte array to hex for conversion to uuid
    , 'hex')::uuid
  WHERE interval_seconds > 0 AND block_num_bytes BETWEEN 1 AND 4
$$;

-----------------------------

Technically affecting the v4 spec. You could always convert to a
UUIDv8, which is the intention behind that new version even though the
standard hasn't been ratified yet.


Cheers,

Miles Elam

Then it's not a Type 4 UUID, which is perfectly fine; just not random.

Also, should now() be replaced by clock_timestamp(), so that it can be 
called multiple times in the same transaction?

On 1/28/23 21:28, Miles Elam wrote:
> On Sat, Jan 28, 2023 at 6:02 PM Ron <ronljohnsonjr@gmail.com> wrote:
>> Type 4 UUIDs are sub-optimal for big table because cache hit rates drop through the floor.
>>
>> This lesson was burned into my psyche waaaay back in the Clinton administration.  It was my task to speed up a five
hourbatch job which read input records from a flat file, did some validations and then inserted them.  Simply sorting
theinput file on the primary key fields -- we used natural keys, not synthetics -- dropped the run time to two hours.
(VMSSORT saved the day, because you could tell it the sort order you wanted; thus, I could preserve the header record
atthe top of the file, and the trailer record at the end of the file without jumping through a bunch of hoops.)
 
> This can be mitigated with judicious use of a sequence at the front of
> the uuidv4.
>
>      https://www.2ndquadrant.com/en/blog/sequential-uuid-generators/
>
> More effort than just calling the built-in gen_random_uuid() or
> equivalent in app code, but a substantial performance gain for your
> effort.
>
>      https://github.com/tvondra/sequential-uuids
>
> And in a managed environment where you can't install custom
> extensions, a fairly simple function with divide on unix epoch seconds
> combined with a call to overlay(...) should suffice performance-wise.
> At 60 seconds, this will loop every 45 days or so, and you can choose
> how much "sequentialness" works for you, from 1 to 4 bytes at the
> expense of pseudo-randomness.
>
> -----------------------------
>
> -- Generate time interval UUID
> CREATE OR REPLACE FUNCTION gen_interval_uuid(interval_seconds int4 =
> 60, block_num_bytes int2 = 2)
> RETURNS uuid LANGUAGE sql VOLATILE PARALLEL SAFE AS $$
>    SELECT encode(
>      overlay(
>        -- convert the uuid to byte array
>        uuid_send(gen_random_uuid())
>        -- use only the bottom bytes
>        PLACING substring(
>            int4send((extract(epoch FROM now()) / interval_seconds)::int4)
>            FROM (5 - block_num_bytes)
>        )
>        -- place at the front two bytes of the uuid
>        FROM 1
>      )
>      -- convert the resulting byte array to hex for conversion to uuid
>      , 'hex')::uuid
>    WHERE interval_seconds > 0 AND block_num_bytes BETWEEN 1 AND 4
> $$;
>
> -----------------------------
>
> Technically affecting the v4 spec. You could always convert to a
> UUIDv8, which is the intention behind that new version even though the
> standard hasn't been ratified yet.
>
>
> Cheers,
>
> Miles Elam
>
>

-- 
Born in Arizona, moved to Babylonia.

On Sat, Jan 28, 2023 at 8:02 PM Ron <ronljohnsonjr@gmail.com> wrote:
>
> Then it's not a Type 4 UUID, which is perfectly fine; just not random.

Yep, which is why it really should be re-versioned to UUIDv8 to be
pedantic. In everyday use though, almost certainly doesn't matter.

> Also, should now() be replaced by clock_timestamp(), so that it can be
> called multiple times in the same transaction?

Not necessary. Instead of 122 bits of entropy, you get 106 bits of
entropy and a new incremented prefix every minute. now() vs
clock_timestamp() wouldn't make a substantive difference. Should still
be reasonably safe against the birthday paradox for more than a
century when creating more than a million UUIDs per second.

On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000@gmail.com> wrote:
> CREATE TABLE test1_UUID ( id bigint,source_id varchar(36) PRIMARY KEY, Name varchar(20) );

Maybe if you used a "native" 16-byte uuid, instead of its textual
serialization with dashes (36 bytes + length overhead), the gap would
narrow.

Dominique Devienne <ddevienne@gmail.com> writes:
> On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000@gmail.com> wrote:
>> CREATE TABLE test1_UUID ( id bigint,source_id varchar(36) PRIMARY KEY, Name varchar(20) );

> Maybe if you used a "native" 16-byte uuid, instead of its textual
> serialization with dashes (36 bytes + length overhead), the gap would
> narrow.

Yeah, especially if your database is not using C locale.  The
strcoll or ICU-based comparisons done on string types can be
enormously more expensive than the memcmp() used for binary
types like native uuid.

            regards, tom lane

On 1/30/23 11:43, veem v wrote:
> Thank You So much for the details. I am a bit new to postgres. And these 
> test results I picked were from a dev system. If I understand it 
> correctly, do you mean these settings(usage of C locale or "native" 
> 16-byte uuid) which you mentioned should be there in a production system 
>   and thus we should test the performance of the UUID vs sequence on a 
> similar setup? Or say if this sort of degradation of UUID performance is 
> not expected then , how to get these settings tweaked ON, so as to see 
> the best string type or UUID performance, can you please guide me here?

No what is being said is change:

source_id varchar(36)

to

source_id uuid

as i:

https://www.postgresql.org/docs/current/datatype-uuid.html

> 
> On Mon, 30 Jan 2023 at 22:18, Tom Lane <tgl@sss.pgh.pa.us 
> <mailto:tgl@sss.pgh.pa.us>> wrote:
> 
>     Dominique Devienne <ddevienne@gmail.com
>     <mailto:ddevienne@gmail.com>> writes:
>      > On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000@gmail.com
>     <mailto:veema0000@gmail.com>> wrote:
>      >> CREATE TABLE test1_UUID ( id bigint,source_id varchar(36)
>     PRIMARY KEY, Name varchar(20) );
> 
>      > Maybe if you used a "native" 16-byte uuid, instead of its textual
>      > serialization with dashes (36 bytes + length overhead), the gap would
>      > narrow.
> 
>     Yeah, especially if your database is not using C locale.  The
>     strcoll or ICU-based comparisons done on string types can be
>     enormously more expensive than the memcmp() used for binary
>     types like native uuid.
> 
>                              regards, tom lane
> 

-- 
Adrian Klaver
adrian.klaver@aklaver.com

And populate that column with UUIDs generated by the gen_random_uuid() function.

(Requires v13.)

On 1/30/23 13:46, Adrian Klaver wrote:
> On 1/30/23 11:43, veem v wrote:
>> Thank You So much for the details. I am a bit new to postgres. And these 
>> test results I picked were from a dev system. If I understand it 
>> correctly, do you mean these settings(usage of C locale or "native" 
>> 16-byte uuid) which you mentioned should be there in a production system 
>>   and thus we should test the performance of the UUID vs sequence on a 
>> similar setup? Or say if this sort of degradation of UUID performance is 
>> not expected then , how to get these settings tweaked ON, so as to see 
>> the best string type or UUID performance, can you please guide me here?
>
> No what is being said is change:
>
> source_id varchar(36)
>
> to
>
> source_id uuid
>
> as i:
>
> https://www.postgresql.org/docs/current/datatype-uuid.html
>
>>
>> On Mon, 30 Jan 2023 at 22:18, Tom Lane <tgl@sss.pgh.pa.us 
>> <mailto:tgl@sss.pgh.pa.us>> wrote:
>>
>>     Dominique Devienne <ddevienne@gmail.com
>>     <mailto:ddevienne@gmail.com>> writes:
>>      > On Mon, Jan 30, 2023 at 5:11 PM veem v <veema0000@gmail.com
>>     <mailto:veema0000@gmail.com>> wrote:
>>      >> CREATE TABLE test1_UUID ( id bigint,source_id varchar(36)
>>     PRIMARY KEY, Name varchar(20) );
>>
>>      > Maybe if you used a "native" 16-byte uuid, instead of its textual
>>      > serialization with dashes (36 bytes + length overhead), the gap would
>>      > narrow.
>>
>>     Yeah, especially if your database is not using C locale. The
>>     strcoll or ICU-based comparisons done on string types can be
>>     enormously more expensive than the memcmp() used for binary
>>     types like native uuid.
>>
>>                              regards, tom lane
>>
>

-- 
Born in Arizona, moved to Babylonia.

On 2023-02-02 10:22:09 -0500, Benedict Holland wrote:
> Well... until two processes generate an identical UUID. That happened to me
> several times.

How did that happen? Pure software implementation with non-random seed?
Hardware with insufficient entropy source?

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

On 2/2/23 17:11, Peter J. Holzer wrote:
> On 2023-02-02 10:22:09 -0500, Benedict Holland wrote:
>> Well... until two processes generate an identical UUID. That happened to me
>> several times.
> How did that happen? Pure software implementation with non-random seed?
> Hardware with insufficient entropy source?

Poorly implemented algorithm?

-- 
Born in Arizona, moved to Babylonia.

> On Feb 2, 2023, at 1:26 PM, Benedict Holland <benedict.m.holland@gmail.com> wrote:
>
> 
> No idea at all. We had the data for the insert and had to insert it again. It was extremely confusing but oh boy did
itwreck our systems. 
>
> Thanks,
> Ben

Someone has a baked-in uuid in a script I suspect.


>

On 2023-02-06 20:04:39 +0100, Julian Backes wrote:
> I don't really understand what you mean by 'performance'. To me it is not
> surprising that incrementing (I know it is not just incrementing) a
> 64bit integer is faster than generating 128 bit data with a good amount of
> random data even if it seems to be too slow.

That's not really the problem with UUIDs, though. My (not very fast)
laptop can call getrandom() 1 million times per second (in a single
thread). Avoiding the system call[1] could make this fast enough to be
completely negligible compared to the time of writing a row to disk.

But UUIDs are random and that plays havoc with locality. For example
consider one table with invoices and another with invoice items. If you
want to get all the invoices including the items of a single day, the
data is probably nicely clustered together in the tables. But the join
needs to look up random ids in the index, which will be spread all over
the index. In a simple benchmark for this scenario the UUIDs were about
4.5 times slower than sequential ids. (In other benchmarks the
difference was only a few percent)

So depending on the querys the difference may be negligible or huge.

It really depends on your access patterns.

        hp


[1] There was even a discussion about making that much faster on the
    LKML recently.


--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

On 2023-02-08 14:48:03 +0530, veem v wrote:
> So wanted to know from experts here, is there really exists any scenario in
> which UUID really cant be avoided?

Probably not. The question is usually not "is this possible" but "does
this meet the requirements at acceptable cost".


> Sequence Number = n*d+m+offset. Where n is the sequence order number, d is the
> dimensions of the multi-master replication, m ranges from 0 to n-1 is the
> number assigned to each node in the replication, and offset is the number to
> offset the sequence numbers. 

Yes, you can do this. In fact, people (including me) have already done
this.

But it's relatively easy to mess this up:

Firstly, you have to make sure that d is larger than your number of
(active) replicas will ever be, but still small enough that you will
never overflow. Probably not a problem with 64 bit sequences (if you set
d to 1E6, you can still count to 9E12 on each node), but might be a
problem if you are for some reason limited to 32 bits.

Secondly (and IMHO more importantly) you have to make sure each node
gets its own unique offset. So this needs to be ensured during
deployment, but also during migrations, restores from backups and other
infrequent events.

With random Ids you don't have to worry about this.

        hp

--
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp@hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"

On Wed, Feb 8, 2023 at 11:56 AM Kirk Wolak <wolakk@gmail.com> wrote:
>
> CREATE FUNCTION generate_ulid() RETURNS uuid
>     LANGUAGE sql
> RETURN ((lpad(to_hex((floor((EXTRACT(epoch FROM clock_timestamp()) * (1000000)::numeric)))::bigint), 14, '0'::text)
>       || encode(gen_random_bytes(9), 'hex'::text)))::uuid;

You can save yourself some CPU by skipping the extra cast, omitting
the lpad, to_hex, and floor, and just grabbing the bytes from the
bigint directly along with the random part since bytea can be
concatenated.

    SELECT encode(int8send((EXTRACT(epoch FROM clock_timestamp()) *
1000000)::bigint)
                  || gen_random_bytes(8), 'hex')::uuid
    ;

Note that you refer to it as a ULID, but it is stored as a UUID.
Hopefully nothing downstream ever relies on UUID versioning/spec
compliance. Now that I think of it, I could probably speed up my
tagged interval UUID implementation using some of this at the expense
of configurability.