Re: WIP: bufmgr rewrite per recent discussions - Mailing list pgsql-patches

From Tom Lane
Subject Re: WIP: bufmgr rewrite per recent discussions
Date
Msg-id 7346.1108655184@sss.pgh.pa.us
Whole thread Raw
In response to Re: WIP: bufmgr rewrite per recent discussions  ("Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk>)
Responses Re: WIP: bufmgr rewrite per recent discussions
List pgsql-patches
"Mark Cave-Ayland" <m.cave-ayland@webbased.co.uk> writes:
> As I see it, there is not much noticeable performance gain (and maybe even a
> small loss)with the padding included.

Looks that way.  Of course we should never trust a single test case very
far, but this suggests that there's not a whole lot of gold to be mined
by padding out the buffer headers.

>> 3. Pad the LWLock struct (in
>> src/backend/storage/lmgr/lwlock.c) to some power of 2 up to
>> 128 bytes --- same issue of space wasted versus cross-lock contention.

> Having seen the results above, is it still worth looking at this?

Yeah, probably, because there are other possible contention sources
besides buffers that might be alleviated by padding LWLocks.  For
instance the buffer manager global locks and the LockMgrLock are
probably all in the same cache line at the moment.

Thanks for running these tests.

            regards, tom lane

pgsql-patches by date:

Previous
From: "Mark Cave-Ayland"
Date:
Subject: Re: WIP: bufmgr rewrite per recent discussions
Next
From: Zhenbang Wei
Date:
Subject: Update Traditional Chinese translations for 8.0 branch