Re: unique row identifier data type exhausted . . .

From: Mark Dalphin <mdalphin(at)amgen(dot)com>
To: pgsql-general(at)postgresql(dot)org
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Subject: Re: unique row identifier data type exhausted . . .
Date: 2000-04-26 16:17:17
Message-ID: 3907168D.7FD5F2BA@amgen.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Bruce Momjian wrote:

> > > Is this necessarily a good solution? If you use 64-bit OIDs, some joker
> > > will just hook up a several-terra-byte disk array to his machine, try to
> > > store the location of every molecule in the universe and break it.
> >
> > If you have to have OIDs at all, its a lot better than a 32 bit number. I
> > think it would be easier to switch to 64 bit OIDs than ditch them
> > completely.
> > The "serial" type should definitely be 64 bit. To make matters worse I
> > believe its really only a 31 bit number as the plus/minus symbol is
> > discarded. But I think moving to 64 bit will take place soon enough, when
> > it needs to, and it should shut everyone up.
>
> If you look at that TODO list, oid's flowing over 32-bits is not
> something we are losing sleep over. In fact, the first fix would be to
> make sure oid's are truly treated as unsigned int's, thereby doubling
> their range. I have done some of those myself, but I am sure there are
> more areas that need fixing.
>
> Illustra's solution was to use two int32's, making the upper 32-bit
> value represent the site, so oid's remain unique as they move between
> sites. If we picked a random 32-bit oid on initdb startup, that would
> pretty much make them unique all the time.
>
> --
> Bruce Momjian | http://www.op.net/~candle
> pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026

While I am working on a system which could use 64-bit OIDs, and I think it is a
good idea to move to them, I wonder if the developers should consider the people
who are running older, "legacy" systems as well. Moving to a 64-bit OID would
add considerably to the space required (ie the overhead) to run the database.
Many Linux systems are "Linux" because Windows got too big and clunky to run
there. If possible, I'd suggest leaving the OID size as a compile time switch
so those who wish to run "light" can do so, and those who wish to tally the
molecules of the universe can think about how to compress the data to fit within
a 64-bit OID.

Mark

--
Mark Dalphin email: mdalphin(at)amgen(dot)com
Mail Stop: 29-2-A phone: +1-805-447-4951 (work)
One Amgen Center Drive +1-805-375-0680 (home)
Thousand Oaks, CA 91320 fax: +1-805-499-9955 (work)

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Charles Tassell 2000-04-26 16:56:27 RE: too many clients - Error message
Previous Message Jim Mercer 2000-04-26 15:10:44 7.0 weirdness (maybe solaris?)