Re: OID wraparound (was Re: pg_depend)

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> I think it should be off on user tables by default, but kept on system
> tables just for completeness.

Clearly, certain system tables *must* have OIDs --- pg_class, pg_type,
pg_operator, etc --- because we use those OIDs to refer to objects.
These are exactly the same tables that have unique indexes on OID.

However, I don't see the point of consuming OIDs for entries in, say,
pg_listener. The notion that it must have OIDs simply because it's
a system table seems silly.

pg_attribute is on the edge --- are table columns objects in their own
right, deserving of a separate OID, or not? So far I don't see any
really good reason why they should have one.

Since the goal is to minimize OID consumption, not assigning OIDs to
pg_attribute entries seems like a good idea. I don't think this is
just a marginal hack. ISTM the main source of OID consumption for an
up-and-running system (if it has no large user tables with OIDs) will be
creation of temp tables. We can expend two OIDs per temp table
(pg_class and pg_type), or we can expend N+9 for an N-column temp table
(the seven system attributes plus the N user ones plus pg_class and
pg_type). That's *at least* a 5x difference in steady-state rate of OID
consumption. If that doesn't get your attention, it should.

regards, tom lane