Bruce Momjian <[EMAIL PROTECTED]> 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
