Re: Proposal: OID wraparound: summary and proposal

At 10:09 AM +0500 8/7/01, Hannu Krosing wrote:
>Neil Tiffin wrote:
>>
>> I would just like to comment that for our project, GNU Enterprise, we
>> use our own 128 bit object ID that is unique (UUID) for every row in
>> all tables.
>>
>> It seems to me, without having looked into it, that having both a
>> PostgreSQL UID and our own 128 bit objectid (UUID) is redundant and
>> slows the whole process down. But we are storing object data in the
>> database and require and absolutely unique objectid. We are planning
>> for enterprise usage and expect to need 128 bits to uniquely define
>> our objects.
>
>Is it just an 128-bit int from a sequence or does it have some internal
>structure ?
>
>What kind of enterprise do you expect to have more than
>18 446 744 073 709 551 615 of objects that can uniquely be identified
>by 64 bits ?

Our objectid is a UUID from libuuid (provided by e2fsprogs, requires
development files. debian package uuid-dev provides all necessary
files.) We use the text representation which IIRC is 33 characters
(38 minus the "-") to store it in the database. (And I dont think
this is the best way to do it.) As for 64 bits being enough, you may
just be right. Our developer that did this part of the code has left
(and we are taking the opportunity to examine this).

We will eventually compete with SAP, Peoplesoft etc. and consider
that SAP has about 20,000 tables to represent an enterprise plus the
life of the system at 10 years and you start to knock down the number
very fast.

I think in the short term we could be happy with a 64 bit id. As we
don't even have our first application working (but we are within a
couple of months) and it will be years before we have a system that
will perform in large scale environments.

In either case the perfect solution, for us, would be to be able to
configure the PostgreSQL uid as none, 64 bit or 128 bit uid at
compile time. A default of 64 bits would be just fine. But we need
to have the uid unique for the database or we will still have to
create and use our own uid (and that will slow everything down).

I have not even considered multiple database servers running
different database, which is our design goal. In this case we would
like to have a slimmed down (and blazingly fast) PostgreSQL server in
which we manage the uid in our middleware. This is because the uid
must be unique accross all servers and database vendors. (I don't
claim to be a database guru, so if we are all wet here please feel
free to help correct our misunderstandings.)

--
Neil
neilt(at)gnue(dot)org
GNU Enterprise
http://www.gnuenterprise.org/
http://www.gnuenterprise.org/~neilt/sc.html