Re: extending relations more efficiently

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Browne <cbbrowne(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: extending relations more efficiently
Date: 2012-05-01 19:01:18
Message-ID: 1335898581-sup-758@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Tom Lane's message of mar may 01 13:19:48 -0400 2012:
> Christopher Browne <cbbrowne(at)gmail(dot)com> writes:
> > Try to make sure that one of the scenarios involves there being
> > multiple writers.
>
> > One of the relevant cases is where there are multiple writers, where
> > they may wind up fighting over the last page in the table. If free
> > space is in that one page, they might serialize on the request for
> > access to that page.
>
> 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.

I haven't tested it recently to see if things have already improved,
though.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2012-05-01 19:17:08 pgsql: Remove dead ports
Previous Message Tom Lane 2012-05-01 18:42:58 Re: Problem with multi-job pg_restore