Re: Moving more work outside WALInsertLock

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Moving more work outside WALInsertLock
Date: 2011-12-15 18:50:52
Message-ID: 4EEA418C.9000304@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 15.12.2011 18:48, Tom Lane wrote:
> Jeff Janes<jeff(dot)janes(at)gmail(dot)com> writes:
>> On Thu, Dec 15, 2011 at 7:34 AM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> This patch may or may not be useful, but this description of it is utter
>>> nonsense, because we already do compute that before taking the lock.
>>> Please try again to explain what you're doing?
>
>> Currently the CRC of all the data minus the header is computed outside the lock,
>> but then the header's computation is added and the CRC is finalized
>> inside the lock.
>
> Quite. AFAICS that is not optional,

Right, my patch did not change that.

> unless you are proposing to remove
> the prev_link from the scope of the CRC, which is not exactly a
> penalty-free change.

We could CRC the rest of the record header before getting the lock,
though, and only include the prev-link while holding the lock. I
micro-benchmarked that a little bit, but didn't see much benefit from
doing just that. Once you do more drastic changes so that the lock
doesn't need to be held while copying the data and calculating the CRC
of the record header, so that those things can be done in parallel, it
matters even less.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2011-12-15 18:55:52 Re: pgstat wait timeout
Previous Message pratikchirania 2011-12-15 18:42:03 Re: pgstat wait timeout