Обсуждение: OID Implicit limit

Поиск
Список
Период
Сортировка

OID Implicit limit

От
"Steve Howe"
Дата:
Hi folks,

       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 ?

Best Regards,
Howe





RE: OID Implicit limit

От
"Christopher Kings-Lynne"
Дата:
> >         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



Re: OID Implicit limit

От
Bruce Momjian
Дата:
We have an FAQ item on this now under OID's.

[ Charset ISO-8859-1 unsupported, converting... ]
> > >         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
> 
> 


--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


Re: OID Implicit limit

От
"Steve Howe"
Дата:
""Christopher Kings-Lynne"" <chriskl@familyhealth.com.au> wrote in message
news:NEBBIOAJBMEENKACLNPCIELGCCAA.chriskl@familyhealth.com.au...
> > >         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