On 2014-12-23 16:42:41 -0500, Robert Haas wrote:
> I don't think I have anything to say about the substance of the patch.
> If fetch-and-add is faster than a spinlock cycle, then it is. And
> it's good to be fast.
I don't think the primary advantage is that it's fast (even though it
should be as
On Tue, Dec 23, 2014 at 3:30 PM, Andres Freund wrote:
> On 2014-12-10 21:52:17 -0500, Robert Haas wrote:
>> Maybe you could store the pgprocno instead of the PROC *.
>
> That's a good idea. Here's a patch implementing that and other things.
Thanks. Cool.
> Changes:
> * The handling of wraparoun
On 2014-12-10 21:52:17 -0500, Robert Haas wrote:
> Maybe you could store the pgprocno instead of the PROC *.
That's a good idea. Here's a patch implementing that and other things.
Changes:
* The handling of wraparound is slight changed. There's a separate patch
for the case where nextVictimBuff
On Mon, Dec 8, 2014 at 2:51 PM, Andres Freund wrote:
> On 2014-10-30 07:55:08 -0400, Robert Haas wrote:
>> On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund
>> wrote:
>> >> But if it is, then how about
>> >> adding a flag that is 4 bytes wide or less alongside bgwriterLatch,
>> >> and just checking
On 2014-10-30 07:55:08 -0400, Robert Haas wrote:
> On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund wrote:
> >> But if it is, then how about
> >> adding a flag that is 4 bytes wide or less alongside bgwriterLatch,
> >> and just checking the flag instead of checking bgwriterLatch itself?
> >
> > Yea,
On Thu, Oct 30, 2014 at 5:01 PM, Andres Freund
wrote:
>
> On 2014-10-30 10:23:56 +0530, Amit Kapila wrote:
> > I have a feeling that this might also have some regression at higher
> > loads (like scale_factor = 5000, shared_buffers = 8GB,
> > client_count = 128, 256) for the similar reasons as bgr
On Wed, Oct 29, 2014 at 3:09 PM, Andres Freund wrote:
>> But if it is, then how about
>> adding a flag that is 4 bytes wide or less alongside bgwriterLatch,
>> and just checking the flag instead of checking bgwriterLatch itself?
>
> Yea, that'd be nicer. I didn't do it because it made the patch sl
On 2014-10-30 10:23:56 +0530, Amit Kapila wrote:
> I have a feeling that this might also have some regression at higher
> loads (like scale_factor = 5000, shared_buffers = 8GB,
> client_count = 128, 256) for the similar reasons as bgreclaimer patch,
> means although both reduces contention around s
On Thu, Oct 30, 2014 at 12:39 AM, Andres Freund
wrote:
> On 2014-10-29 14:18:33 -0400, Robert Haas wrote:
>
> > The interaction between this and the bgreclaimer idea is interesting.
> > We can't making popping the freelist lockless without somehow dealing
> > with the resulting A-B-A problem (name
On 2014-10-29 14:18:33 -0400, Robert Haas wrote:
> On Mon, Oct 27, 2014 at 9:32 AM, Andres Freund wrote:
> > I've previously posted a patch at
> > http://archives.postgresql.org/message-id/20141010160020.GG6670%40alap3.anarazel.de
> > that reduces contention in StrategyGetBuffer() by making the cl
On Mon, Oct 27, 2014 at 9:32 AM, Andres Freund wrote:
> I've previously posted a patch at
> http://archives.postgresql.org/message-id/20141010160020.GG6670%40alap3.anarazel.de
> that reduces contention in StrategyGetBuffer() by making the clock sweep
> lockless. Robert asked me to post it to a ne
Hi,
I've previously posted a patch at
http://archives.postgresql.org/message-id/20141010160020.GG6670%40alap3.anarazel.de
that reduces contention in StrategyGetBuffer() by making the clock sweep
lockless. Robert asked me to post it to a new thread; I originally
wrote it to see some other contenti
12 matches
Mail list logo
