Excerpts from Simon Riggs's message of mar feb 07 10:46:09 -0300 2012:
> Recent events have made me notice the OID handling.
>
> AFAICS, OIDs are just a sequence with a max value that fits in a uint.
>
> So ISTM that we should just strip out the OID handling code and just
> have a system sequence defined like this
>
> CREATE SEQUENCE _pg_oid
> MINVALUE 0
> MAXVALUE 4294967296
> CACHE 8192
> CYCLE;
>
> Which would then make it easier to have a sequence for each toast
> table and a sequence for lobs.
Yeah, I agree that having a single sequence to handle oid allocations on
all toast tables across all databases is strange. I don't have evidence
that this is a real scalability problem though. But theoretically at
least it seems to me that there could sporadically be a problem if a
table has a long string of allocated OIDs and the system OID generator
wraps around to somewhere within that range to allocate a new one for
that table. That could cause a long period of spinning to get a new
value, thus high latency on that insert.
(Now admittedly if the same were to happen with a non-shared sequence,
it would have to spin just the same -- but it'd do so without having to
grab a system-level lwlock each time.)
Having one sequence for each toast table could be wasteful though. I
mean, sequences are not the best use of shared buffer cache currently.
If we could have more than one sequence data in a shared buffer page,
things would be different. Not sure how serious this really is.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support