Re: UUID v1 optimizations...
Morris de Oryx <[email protected]>
| Newsgroups | gmane.comp.db.postgresql.performance |
|---|---|
| Message-ID | <CAKqncchpJg0AETb2ouvCzyap-htiyv6LN6ne+JnU9Jo4Ogt9HA@mail.gmail.com> |
On Sun, May 26, 2019 at 8:37 PM Tomas Vondra <[email protected]> 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.