RE: 4 billion record limit?

True, it is a big number and for most people I would agree with what you are saying.
Computationally the amount of activity on the database needed to use up that sort of
number is immense. But then, two years ago the prospect of a 1GHz PC processor was also
remote.

I can only say that OpenSource is exploding across the computing landscape more comprehensively
and faster than anyone thought possible and at the same time supercomputing is becoming the
order of the day rather than that rare place that you hoped to be invited into. Linux has
made this possible and OpenSource is at the very heart of this.

I would personally like to see PostgreSQL being synonymous with OpenSource installations.
To a large degree it has already achieved that. In my own experience working with datbases
of several TB in size is now becoming normal rather than exceptional.

I guess that what I am trying to say is that if the OID limit reflected the maximum storage
capacity of the system (more easily determined) rather than a transactional capacity (a lot
less easily dealt with) it would be a major feather in Postgres' cap.

However, my guess would be that were someone to write a mechanism for choosing the OID
handling algorithm, the payoff between performance/transaction limits would mean that
probably most would opt for the performance gain and deal with the OID issue as a normal
DBA procedure. I know that I would for the majority of databases that I administer.

Brad


Quoting Andrew Snow <als@fl.net.au>:

>
> > Simply waiting for 64bit numbers is rather inelegant and also
> > presumes usage
> > parameters for the database... remember Bill Gates saying that he
> couldn't
> > foresee any usage for more than 64MB of RAM?
>
> I've heard this before and I just don't agree.  64MB ram, perhaps, but who
> is going to need 64 * 2^32?  The magnitude of increase is fairly vast!
>
> I probably need not mention that a 32 bit value can store up to
> 4,294,967,296 where a 64 bit number can store a number that is
> 4,294,967,296
> times as big. If 32 bit wasn't enough to keep you happy for more than a few
> years, a 64 bit oid really should be enough for anyone for long enough that
> you won't be using the same software/hardware any more.
>
> Similar to how a 32 bit unix time in seconds is only good for another ~40
> years, but a 64 bit one will keep us going for billions of years.
>
> I guess the real issue is rewriting the system so that the type of oid can
> be chosen at compile time, so you can use whatever damn one you feel like.
> I would also guess that the majority of systems out there using the latest
> versions of postgres, already have compiler support for 64 bit integers.
> So
> when someone gets around to doing the necessary work, everything will be
> nice.
>
>
> - Andrew
>
>
> P.S. IMHO if you can't afford to do a drop and reload once in a while,
> Postgres isn't a good choice at the moment for your application.
>
>
>
>



Bradley Kieser
Director
  Kieser.net