Disclaimer: Out over my skis again.
>From what you say here, and over on SO, it sounds like you've got two
problems:
* Matching on *huge *numbers of records because of common tags.
* A dynamic collection of tags as they're customer driven/configured.
An "ideal" solution might look like a
On Sun, May 26, 2019 at 8:37 PM Tomas Vondra
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)
.
But that particular trade-off is an ancient discussion and judgement call,
you know your requirements and constraints better than anyone else. So,
I'll leave it at that.
On Sun, May 26, 2019 at 8:24 PM Morris de Oryx
wrote:
> On Sun, May 26, 2019 at 7:38 PM Ancoron Luciferis <
> ancor
On Sun, May 26, 2019 at 7:38 PM Ancoron Luciferis <
ancoron.lucife...@googlemail.com> wrote:
The BRIN index is something I might need to test, though.
>
Yes, check that out, it might give you some ideas. A B-tree (in whatever
variant) is *inherently *a large index type. They're ideal for finding
I'm not worthy to post here, but a bit of a random thought.
If I've followed the conversation correctly, the reason for a V1 UUID is
partly to order and partition rows by a timestamp value, but without the
cost of a timestamp column. As I was told as a boy, "Smart numbers aren't."
Is it
