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 <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers