Re: Patch for UUID datatype (beta)

Gevik,
>uniqueness is never a guaranteed. that is according to the RFC docs.

>uniqueness is never a guaranteed in the sense that there is a tiny
>chance someone of the other side of the planet might generate the same
>guid.

As much as I learned, it is recommended to give information about "grade of uniqueness". I think it would be a valuable information, which information your UUID-generator takes into account, and what the "grade of uniqueness" is.

(I know of the Windows UUID, which takes the MAC-Address of the included Ethernet-Card into it's calculation, which may be guaranteed to be unique)


Some more questions about UUIDs and your patch:

a) compatibility of UUIDs   -> I have generated a lot of UUIDs via the WIN32 provided function (for the unix-only-people: Windows uses UUIDs all around its registry, software IDs and on and on). How unique are those UUIDs when mixed with "your" UUIDs ?

b) I read some time ago about the problems with UUIDs as primary keys in contrast to serials: serials get produced in ascending order; and often data which was produced in one timespan is also connected semantically. "near serial values" are also local within a btree-index; but UUIDs generated in "near times" are usually spread around the possible bitranges.
(example for sequence of serials: 1 - 2 - 3 - 4 - 5 - 6
 example for sequence of UUIDs : 1 - 999919281921843191 - 782 - 18291831912318971231)
that is supposed to affect the locality of the index, and from that also the performance of the system.

I do not know how valid this information is; so I am asking you for your feedback; especially since you put a lot of thoughts into this UUID patch. Maybe you took allready care of this situation when constructing the index operators?

Thanks

Harald






--
GHUM Harald Massa
persuadere et programmare
Harald Armin Massa
Reinsburgstraße 202b
70197 Stuttgart
0173/9409607
-
Let's set so double the killer delete select all.