Skip site navigation (1) Skip section navigation (2)

Re: extending relations more efficiently

From: Christopher Browne <cbbrowne(at)gmail(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: extending relations more efficiently
Date: 2012-05-01 17:12:55
Message-ID: CAFNqd5XKq0o8z5VBNa5NMp6KZwKvsC0SSeNyHJSTK=KWXpPdog@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Tue, May 1, 2012 at 10:22 AM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
> On Tue, May 1, 2012 at 3:08 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> We've previously discussed the possible desirability of extending
>> relations in larger increments, rather than one block at a time, for
>> performance reasons.  I attempted to determine how much performance we
>> could possibly buy this way, and found that, as far as I can see, the
>> answer is, basically, none.
>
> Fair enough, but my understanding was that tests showed that the
> extension lock was a bottleneck, so doing extensions in larger chunks
> should reduce the time we spend waiting for a lock and thus improve
> performance. So while your results here show no gain, there is gain to
> be had elsewhere as a result.

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.

Extending by several pages at a time may help *one* of the writers,
but if that adds some I/O work that takes place while other
connections are blocked, waiting, then this might worsen things
somewhat for the other writers.  If this reduces the frequency of that
sort of collision, it might nonetheless be a win.
-- 
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2012-05-01 17:15:11
Subject: Re: proposal: additional error fields
Previous:From: Tom LaneDate: 2012-05-01 16:59:00
Subject: Re: Problem with multi-job pg_restore

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group