On 2015-09-08 14:31:53 -0400, Robert Haas wrote:
> On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund wrote:
> > On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
> >> We could do that, but I'm not sure just calling LWLockNewTrancheId()
> >> for all of the tranches would be so bad either.
> >
> > To me
On Tue, Sep 8, 2015 at 2:19 PM, Andres Freund wrote:
> On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
>> We could do that, but I'm not sure just calling LWLockNewTrancheId()
>> for all of the tranches would be so bad either.
>
> To me that seems either fragile or annoying to use. If all backends
On 2015-09-08 14:15:32 -0400, Robert Haas wrote:
> We could do that, but I'm not sure just calling LWLockNewTrancheId()
> for all of the tranches would be so bad either.
To me that seems either fragile or annoying to use. If all backends call
LWLockNewTrancheId() we need to a be sure the callbacks
On Tue, Sep 8, 2015 at 1:54 PM, Andres Freund wrote:
> On 2015-09-08 13:29:28 -0400, Robert Haas wrote:
>> I like this approach, though I think clearly it needs more performance
>> testing.
>
> Yea, obviously. I did run this on a slightly bigger machine yesterday
> and it gave consistent ~8% perf
On 2015-09-08 13:29:28 -0400, Robert Haas wrote:
> I like this approach, though I think clearly it needs more performance
> testing.
Yea, obviously. I did run this on a slightly bigger machine yesterday
and it gave consistent ~8% performance improvements.
> The method of determining the tranche
On Mon, Sep 7, 2015 at 1:59 PM, Andres Freund wrote:
> On 2015-09-06 15:28:40 +0200, Andres Freund wrote:
>> Hm. I found that the buffer content lwlocks can actually also be a
>> significant source of contention - I'm not sure reducing padding for
>> those is going to be particularly nice. I think
On 2015-09-06 15:28:40 +0200, Andres Freund wrote:
> Hm. I found that the buffer content lwlocks can actually also be a
> significant source of contention - I'm not sure reducing padding for
> those is going to be particularly nice. I think we should rather move
> the *content* lock inline into the
Hi,
On 2015-09-06 14:10:24 +0100, Simon Riggs wrote:
> It separates the Buffer LWLocks from the main LW locks, allowing them to
> have different padding.
>
> Tests showed noticeable/significant performance gain due to reduced false
> sharing on main LWlocks, though without wasting memory on the b
Looks like the right time to post this patch.
It separates the Buffer LWLocks from the main LW locks, allowing them to
have different padding.
Tests showed noticeable/significant performance gain due to reduced false
sharing on main LWlocks, though without wasting memory on the buffer
LWlocks.
-
