Re: OID Perfomance - Object-Relational databases

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: OID Perfomance - Object-Relational databases
Date: 2000-10-09 01:56:39
Message-ID: 200010090156.VAA28786@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

[ Charset ISO-8859-1 unsupported, converting... ]
> Tom,
>
> > The trouble with pg_dump -o is that after reload, the OID
> > generator
> > will be set to max(any OID in the dumped data). So a
> > dump & reload
> > doesn't do anything to postpone OID-wraparound Ragnarok.
> >
> > As for the likelihood of overflow, figure 4G / tuple
> > creation rate
> > for your installation (not database, but whole
> > installation controlled
> > by one postmaster). Unless your installation has just
> > one active
> > table, per-table sequence values look like a better bet.
>
> Somebody (urgently) needs to tell all of the above to Bruce
> Momjian (I've cc'd him); his book-in-the-making points up
> OID's as a convenient and universal way to identify and link
> tuples (chapter 7) and doen't mention these problems. Who
> can I bug about how useless the above makes OID's?
>

Well, you know, everyone complains about wrap-around, but no one has
ever reported it happening. It is like the Y2K thing where everyone
thought they would starve. Please, someone tell me they have had had
OID rollover, and I will start doing something about it.

Also, 500 million transactions a day? Seems impossible to me.

--
Bruce Momjian | http://candle.pha.pa.us
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

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Peter Mount 2000-10-09 12:42:07 Re: Loading JDBC Driver
Previous Message Craig May 2000-10-07 03:52:06 Windows 9X