> 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 t
> > When done that way, you're going to see a lot of index B-tree
> > fragmentation with even DCE 1.1 (ISO/IEC 11578:1996) time based
UUIDs,
> > as described above. With random (version 4) or hashed based (version
3
> > or 5) UUIDs there's nothing that can be done to improve the
situation,
> > obvi
> Heikki Linnakangas <[EMAIL PROTECTED]> writes:
> > I believe he means that with his modified comparison function, when
> > inserting a series of UUIDs with increasing time-fields, the index
keys
> > are always inserted to the rightmost page, which gives a more
tightly
> > packed index than scatte
> >> I've been testing the new UUID functionality in 8.3dev and noticed
that
> >> UUIDs are sorted using memcmp in their default in-memory layout,
> >> ...
> >> When done that way, you're going to see a lot of index B-tree
> >> fragmentation with even DCE 1.1 (ISO/IEC 11578:1996) time based
UUIDs,
I've been testing the new UUID functionality in 8.3dev and noticed that
UUIDs are sorted using memcmp in their default in-memory layout, which
is:
struct uuid {
uint32_ttime_low;
uint16_ttime_mid;
uint16_ttime_hi_and_version
