From: | Morris de Oryx <morrisdeoryx(at)gmail(dot)com> |
---|---|
To: | pgsql-performance(at)lists(dot)postgresql(dot)org |
Subject: | Re: UUID v1 optimizations... |
Date: | 2019-05-26 10:46:21 |
Message-ID: | CAKqncchpJg0AETb2ouvCzyap-htiyv6LN6ne+JnU9Jo4Ogt9HA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Mariel Cherkassky | 2019-05-27 08:49:13 | improve wals replay on secondary |
Previous Message | Morris de Oryx | 2019-05-26 10:38:31 | Re: UUID v1 optimizations... |