>
> > The way I see it there are 4 options for the OID:
>
What about a vacuum analyze for the database that renumbers theOIDs
back at some baseline? There is still a limitation on the total number
of active rows in the database (0.5 * 2^32), but at least we wouldn't
have this timebomb.
Dale Joh
Neil Padgett <[EMAIL PROTECTED]> writes:
> mlw wrote:
>> The way I see it there are 4 options for the OID:
> [snip]
>> (2) Allow the ability to have tables without OIDs. This is a source of
>> debate.
> I think Tom Lane has already committed some patches to allow for this.
> So, I think you shoul
mlw wrote:
> The way I see it there are 4 options for the OID:
[snip]
> (2) Allow the ability to have tables without OIDs. This is a source of
> debate.
I think Tom Lane has already committed some patches to allow for this.
So, I think you should be able to try this from the latest CVS. (Tom?)
mlw <[EMAIL PROTECTED]> writes:
> Somehow I guess I created a misunderstanding. I don't really care about
> ROWID. I care that OID is a 32 bit number. The notion that each table could
> have its own "OID" similar to a ROWID could be an intermediate solution. I
> have flip-flopped a couple times a
Somehow I guess I created a misunderstanding. I don't really care about
ROWID. I care that OID is a 32 bit number. The notion that each table could
have its own "OID" similar to a ROWID could be an intermediate solution. I
have flip-flopped a couple times about whether or not the OID being able t
Hannu Krosing <[EMAIL PROTECTED]> writes:
> Will it be easier to make Relation shared and persistent or creating
> a new shared structure that has just a counter+lock for each
> relation oid ?
The latter. Relation (by which I mean a whole relcache entry with all
its subsidiary structure, not o
Tom Lane wrote:
>
> mlw <[EMAIL PROTECTED]> writes:
> > Am I being overly simplistic?
>
> Yes. For one thing, Relation structs are *not* shared, nor even
> persistent (the relcache will happily discard them).
Will it be easier to make Relation shared and persistent or creating
a new shared s
Could we modify the Relation structure to hold an Oid counter? So every where
Postgres calls "newoid(void)" it gets changed to pass the relation structure it
will be associated with, i.e. newoid(Relation *). That way, every relation
could have its own counter, AND perhaps its own spinlock. Relatio
mlw <[EMAIL PROTECTED]> writes:
> Am I being overly simplistic?
Yes. For one thing, Relation structs are *not* shared, nor even
persistent (the relcache will happily discard them). For another, you
haven't mentioned how we keep the counter up-to-date across system
restarts.
mlw wrote:
>
> Zeugswetter Andreas SB SD wrote:
> >
> > > It seems to me, I guess and others too, that the OID mechanism should
> > be on a
> > > per table basis. That way OIDs are much more likely to be unique, and
> > TRUNCATE
> > > on a table should reset it's OID counter to zero.
> >
> > Seem
On Mon, 6 Aug 2001, mlw wrote:
> Zeugswetter Andreas SB SD wrote:
> >
> > > It seems to me, I guess and others too, that the OID mechanism should
> > be on a
> > > per table basis. That way OIDs are much more likely to be unique, and
> > TRUNCATE
> > > on a table should reset it's OID counter to
Zeugswetter Andreas SB SD wrote:
>
> > It seems to me, I guess and others too, that the OID mechanism should
> be on a
> > per table basis. That way OIDs are much more likely to be unique, and
> TRUNCATE
> > on a table should reset it's OID counter to zero.
>
> Seems to me, that this would be no
12 matches
Mail list logo
