Re: UUID v1 optimizations...

On Sun, May 26, 2019 at 8:37 PM Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
wrote:

No, an extra column is not a solution, because it has no impact on the
> index on the UUID column.

Possibly talking at cross-purposes here. I was honing in on the OPs wish to
search and sort by creation order. For which my first (and only) instinct
would be to have a timestamp. In fact, the OP wants to work with multiple
subcomponents encoded in their magic number, so I'm likely off base
entirely. I have a long-standing allergy to concatenated key-like fields as
they're opaque, collapse multiple values into a single column (0NF), and
inevitably (in my experience) get you into a bind when requirements change.

But everyone's got their own point of view on such judgement calls. I'm not
currently dealing with anything where the cost of adding a few small,
fixed-type columns would give me a moment's hesitation. I'm sure we all
like to save space, but when saving space costs you clarity, flexibility,
and compute, the "savings" aren't free. So, it's a judgment call. The OP
may well have 1B rows and really quite good reasons for worrying about
disk-level optimizations.