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
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 |