Re: OID Implicit limit

""Christopher Kings-Lynne"" <chriskl(at)familyhealth(dot)com(dot)au> wrote in message
news:NEBBIOAJBMEENKACLNPCIELGCCAA(dot)chriskl(at)familyhealth(dot)com(dot)au(dot)(dot)(dot)
> > > Reading the documentation, I see that OIDs are unique through
> the
> > > whole database.
> > > But since OIDs are int4, does that limit the number of rows I
> can
> > > have in a database to 2^32 = 4 billion ?
> >
> > Yep.
> >
> > Thanks for the answer - although that concerns me a bit.
> > Maybe I could recompile it setting oid to int64 type...
>
> If that really concerns you, then the rest of the hackers list I think
would
> be very interested in hearing of a real-world database with more than 4
> billion rows/inserts/deletes.
>
> Apparently it is somewhat more complicated than just 'recompiling as an
> int64' to change this. I believe that patches are currently being made to
> facilitate a future move towards 64bit OIDs, but I am not certain of the
> status.
>
> Chris

It won't for sure have 4 billion records *at a time*. But will easyly
process (insert/small calculations/summarize/delete) up to 10 or
20 million records per day.
But not all records will be deleted; I'll run into key conflicts
if the oid sequence generator cross the 2^32 boundary. That is my problem.
But sure, that will take some time to happen (215 days for 20 millions
rows/day).
That means I'll have to be able to do 231,48148148 inserts per second plus
the time to delete and aggregate the data.

> Apparently it is somewhat more complicated than just 'recompiling as an
>int64' to change this. I believe that patches are currently
>being made to
>facilitate a future move towards 64bit OIDs, but I am not certain of the
>status.
Well I hope until there I don't have the key conflicts I mentioned. It will
be hard to, anyway - but possible.

Best regards,
Howe