Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance - Mailing list pgsql-hackers

From Andres Freund
Subject Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance
Date
Msg-id 20190508183114.n6au2yddwntwr2dj@alap3.anarazel.de
Whole thread Raw
In response to Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance  (Andrey Borodin <x4mmm@yandex-team.ru>)
List pgsql-hackers
Hi,

On 2019-05-08 21:35:06 +0500, Andrey Borodin wrote:
> > 8 мая 2019 г., в 1:16, Andres Freund <andres@anarazel.de> написал(а):
> > 
> > We probably can't remove the ringbuffer concept from these places, but I
> > think we should allow users to disable them. Forcing bulk-loads, vacuum,
> > analytics queries to go to the OS/disk, just because of a heuristic that
> > can't be disabled, yielding massive slowdowns, really sucks.
> 
> If we will have scan-resistant shared buffers eviction strategy [0] -
> we will not need ring buffers unconditionally.

For me that's a fairly big if, fwiw. But it'd be cool.


> Are there any other reasons to have these rings?

Currently they also limit the amount of dirty data added to the
system. I don't think that's a generally good property (e.g. because
it'll cause a lot of writes that'll again happen later), but e.g. for
initial data loads with COPY FREEZE it's helpful. It slows down the
backend(s) causing the work (i.e. doing COPY), rather than other
backends (e.g. because they need to evict the buffers, therefore first
needing to clean them).

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance
Next
From: Tom Lane
Date:
Subject: Unexpected "shared memory block is still in use"