Re: [Testperf-general] Re: ExclusiveLock

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, testperf-general(at)pgfoundry(dot)org
Subject: Re: [Testperf-general] Re: ExclusiveLock
Date: 2004-11-18 23:37:40
Message-ID: 1100821059.4113.10647.camel@localhost.localdomain
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2004-11-18 at 23:19, Tom Lane wrote:
> Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> > Would it be possible to: when a new block is allocated from the relation
> > file (rather than reused), we check the FSM - if it is empty, then we
> > allocate 8 new blocks and add them all to the FSM. The next few
> > INSERTers will then use the FSM blocks normally.
>
> Most likely that would just shift the contention to the WALInsertLock.

Well, removing any performance bottleneck shifts the bottleneck to
another place, though that is not an argument against removing it.

Can we subdivide the WALInsertLock so there are multiple entry points to
wal_buffers, based upon hashing the xid? That would allow wal to be
written sequentially by each transaction though slightly out of order
for different transactions. Commit/Abort would all go through the same
lock to guarantee serializability.

--
Best Regards, Simon Riggs

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2004-11-18 23:42:04 Re: OpenBSD/Sparc status
Previous Message Tom Lane 2004-11-18 23:19:52 Re: [Testperf-general] Re: ExclusiveLock