Re: Bulk Insert tuning

From: "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>
To: "Gavin Sherry" <swm(at)alcove(dot)com(dot)au>
Cc: "Simon Riggs" <simon(at)2ndquadrant(dot)com>, <pgsql-patches(at)postgresql(dot)org>
Subject: Re: Bulk Insert tuning
Date: 2008-03-11 13:04:35
Message-ID: 47D68363.8090009@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-patches

Gavin Sherry wrote:
> On Tue, Feb 26, 2008 at 02:43:51PM +0000, Simon Riggs wrote:
>> Following patch implements a simple mechanism to keep a buffer pinned
>> while we are bulk loading.
>
> CK Tan and I worked on something similar but the problem we discovered
> was self locking. Consider a primary key: we insert a tuple into a
> buffer and do not release the exclusive lock. The btree code fetches the
> buffer and tries to share lock it, but we've already exclusive locked
> it. Oops. The performance improvement, though, makes it worth seeing if
> there is a solution.

That's not a problem if you only keep the buffer pinned, not locked. In
my experience, pinning is the more expensive part, with the lookup into
the buffer lookup table. Locking isn't free either, of course, but just
avoiding the pin+unpin would help a lot.

--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com

In response to

Browse pgsql-patches by date

  From Date Subject
Next Message Pavan Deolasee 2008-03-11 13:06:33 Re: [PERFORM] Very slow (2 tuples/second) sequential scan after bulk insert; speed returns to ~500 tuples/second after commit
Previous Message Heikki Linnakangas 2008-03-11 12:57:23 Re: TransactionIdIsInProgress() cache