Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance
Дата
Msg-id 20190508183114.n6au2yddwntwr2dj@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance  (Andrey Borodin <x4mmm@yandex-team.ru>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Detrimental performance impact of ringbuffers onperformance
Следующее
От: Tom Lane
Дата:
Сообщение: Unexpected "shared memory block is still in use"