On Fri, Jun 15, 2007 at 11:05:01AM -0400, Robert Wojciechowski wrote:
> 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.
It's a leap from extracting the UUID as time, to sorting by UUID for
results, or an assumption that reduced fragmentation would increase
performance for regular loads.
> 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.
Therefore fragmented by your assertion, therefore a performance
problem. If your premise is correct, the conclusion that it leads to
is that UUIDv1 will perform better under PostgreSQL.
> So far this ordering method seems to satisfy both needs, but my
> performance analysis will reveal more.
The word "satisfy" above is loosely defined. The existing model
"satisfies" both needs. You believe you have a case that would prove
that the existing model is sub-optimal. You would like to make a
change which you believe would optimize your own use, at the minimal
expense of other users. The minimal expense comes from the more
complicated comparator function, and the confusion of any who see
their non-UUIDv1 UUID's sorted by some apparently arbitrary scheme
that seems to have a history of assuming that UUIDv1 will be used.
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all and in the darkness
bindthem...
http://mark.mielke.cc/