Added to TODO:
* Improve WAL concurrency by increasing lock granularity
http://archives.postgresql.org/pgsql-hackers/2008-02/msg00556.php
---
Simon Riggs wrote:
>
> Paul van den Bogaard (Sun) suggested to me that we co
On Thu, 2008-02-14 at 16:50 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > On Thu, 2008-02-14 at 13:52 -0500, Tom Lane wrote:
> >> [ still staring at the code ... ] Something that might be interesting
> >> though is to try to move some of the buffer control logic overhead out
Simon Riggs <[EMAIL PROTECTED]> writes:
> On Thu, 2008-02-14 at 13:52 -0500, Tom Lane wrote:
>> [ still staring at the code ... ] Something that might be interesting
>> though is to try to move some of the buffer control logic overhead out
>> of WALInsertLock's domain and into WALWriteLock's domai
On Thu, 2008-02-14 at 13:52 -0500, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > Paul van den Bogaard (Sun) suggested to me that we could use more than
> > two WAL locks to improve concurrency.
>
> After looking over the code I'm unconvinced that there's much win to be
> bought thi
Simon Riggs <[EMAIL PROTECTED]> writes:
> Paul van den Bogaard (Sun) suggested to me that we could use more than
> two WAL locks to improve concurrency.
After looking over the code I'm unconvinced that there's much win to be
bought this way. I had been thinking you could push a material amount
of
Simon Riggs <[EMAIL PROTECTED]> writes:
> LWLockAcquire(WALInsertLock, LW_EXCLUSIVE)
> Reserve space to write into.
> LSN = current Insert pointer
> Move pointer forward by length of data to be inserted, acquiring
> WALWriteLock if required to ensure space is available.
I think you've handwaved
Paul van den Bogaard (Sun) suggested to me that we could use more than
two WAL locks to improve concurrency. I think its possible to introduce
such a scheme with some ease. All mods within xlog.c
The scheme below requires an extra LWlock per WAL buffer.
Locking within XLogInsert() would look lik
