> I suggest that treating the UUID as anything other than a unique
> random value is a mistake. There should be no assumptions by users
> with regard to how the order is displayed.
You can always use random UUIDs -- that's a choice in UUID generation.
When dealing with random UUIDs you also (by the very nature of them
being random) would never order by column as it just doesn't make sense.
Nothing changes as long as you generate random UUIDs.
Also, treating UUIDs as time based is completely valid -- that is the
point of version 1
UUIDs. They have quite a few advantages over random UUIDs.
> Also, as UUID generation
> based on time is always in sequence, it seems to me that sorting by
> UUID time would have the effect of inserts always being to the end of
> the index. While this might pack tightly, wouldn't this hurt
> concurrency? Random access vs sequential performance. For UUID, I
> would value random access before sequential performance. Why would
> anybody scan UUID through the index in "sequential" order?
>
Ordering random UUIDs as if they were time-based will still result in
random access on the b-tree, so again luckily this just relies on how
you generate the UUIDs not how you order them.
So far this ordering method seems to satisfy both needs, but my
performance analysis will reveal more.
-- Robert