There is an FAQ item about oid's already on the web site. It may not
be in 7.0.2.
> Tom, Bruce,
>
> Thanks. I think that gives me a pretty clear picture. How can we
> submit this whole OID thing to the PGSQL FAQ? Want me to write it up?
>
> -Josh
Tom, Bruce,
Thanks. I think that gives me a pretty clear picture. How can we
submit this whole OID thing to the PGSQL FAQ? Want me to write it up?
-Josh Berkus
P.S. BTW, my conclusion based on this discussion is that I will not use
the OIDs for
[ Charset ISO-8859-1 unsupported, converting... ]
> Bruce, Tom, etc.:
>
> > > This is what I mean. Does the DB engine only recycle
> > > *unused* OIDs (that is, does it check for teh continued
> > > existance of a tuple with OID 198401)? If that's the
> > > method, then there isn't really a pro
Bruce, Tom, etc.:
> > This is what I mean. Does the DB engine only recycle
> > *unused* OIDs (that is, does it check for teh continued
> > existance of a tuple with OID 198401)? If that's the
> > method, then there isn't really a problem even if I do
> use
> > OIDs as a primary index. None of
ruce,
> The oid counter is preserved with -o on reload. It is
> not reset.
I'll let you and Tom duke this one out. :-) It's all
beyond
me.
> > 2. When OID's "wrap around" does the whole database
go
> > kablooie? If so, why hasn't it happened to anyone
yet?
> If
[ 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 likel
Title: RE: [SQL] OID Perfomance - Object-Relational databases
I'm a little concerned about all this, because my understanding is that what makes an object database so fast is its ability to directly reference tuples, so that traversing relationships becomes like traversing pointers.
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 inst
Josh Berkus <[EMAIL PROTECTED]> writes:
> SO I'm concerned about the problems you mentioned above. pg_dump has a
> -o option; are there problems with this? And how liekly are counter
> overflow problems?
The trouble with pg_dump -o is that after reload, the OID generator
will be set to max(any
Michael Fork <[EMAIL PROTECTED]> writes:
> Just a thought, but couldn't you create a sequence that is referenced by
> multiple tables,
I was going to suggest exactly that. It's not quite as simple as a
"serial" column declaration, but you can split the use of an ID sequence
generator over just a
Just a thought, but couldn't you create a sequence that is referenced by
multiple tables, ie:
CREATE SEQUENCE test_seq;
CREATE TABLE tblclients {
client_id default nextval('test_seq'::text),
...
}
CREATE TABLE tblbills {
bill_id default nextval('tes
Tom,
> By and large I'd recommend using a serial column in preference to OIDs,
> though, for two reasons:
>
> 1. dump/restore is more practical that way (don't have to worry about
>saving/reloading OIDs).
>
> 2. counter overflow problems hit you only per-table, not
>per-installation.
H
Josh Berkus <[EMAIL PROTECTED]> writes:
> 1. Is there a performance loss on searches and joins when I use the OID
> as a liniking field as opposed to a SERIAL column?
> 2. Can I define my own index on the OIDs of a table?
There is absolutely no magic about OIDs, except that the system insists
on
Title: RE: [SQL] OID Perfomance - Object-Relational databases
Regarding all of this, can someone tell me in a fairly
technical manner what the difference is between searching for a row using it's
primary key, and searching using it's OID. Rumour has it that it's
faster. Tech
Title: RE: [SQL] OID Perfomance - Object-Relational databases
Unsigned, I think you can double it, although I haven't applied much thought to this, so I could well be wrong.
>> -Original Message-
>> From: Mitch Vincent [mailto:[EMAIL PROTECTED]]
>> Sent
TED]>
Cc: "Jeff MacDonald" <[EMAIL PROTECTED]>
Sent: Tuesday, October 03, 2000 9:17 AM
Subject: RE: [SQL] OID Perfomance - Object-Relational databases
> Hi, Josh,
>
> In fact, the last point about OIDs is particularly pertinent, because we
are
> expected to proc
Title: RE: [SQL] OID Perfomance - Object-Relational databases
Hi, Josh,
In fact, the last point about OIDs is particularly pertinent, because we are expected to process up to 500 million records daily, thus exhausting the limit in, um, eight days.
Is anybody aware of when this limit will
Folks,
Because it's a very elegant solution to my database structure issues,
I'm using OID's extensively as referents and foriegn keys. However, I
wanted to see if others had previous experience in this (answer as many
as you like):
1. Is there a performance loss on searches and joins w
18 matches
Mail list logo
