On Tue, May 1, 2012 at 3:01 PM, Alvaro Herrera <alvhe...@commandprompt.com> wrote: >> The system is supposed to be designed to avoid that; we try to hand out >> pages with free space to different backends. One of the advantages of >> the current page-at-a-time setup is that when there is *no* free space >> according to the FSM, each such backend will create and fill its own >> page independently. They do serialize on the extension lock, but the >> intervening tuple additions are parallelized. We have to be careful to >> not make that case worse in a multi-page-extension scheme. > > This didn't work all that well for toast tables that have lots of very > large tuples inserted concurrently, at least with older releases. Each > backend would acquire the extension lock many times per tuple inserted. > The result was really high contention on the extension lock.
Hmm, this sounds like a good test case - a small number of SQL statements triggering a large amount of relation extension work. Using an unlogged table would probably make it easier to see the relation-extension contention, too, since you'd get WALInsertLock mostly out of the way. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
