Re: Speed-up shared buffers prewarming
От | Melanie Plageman |
---|---|
Тема | Re: Speed-up shared buffers prewarming |
Дата | |
Msg-id | CAAKRu_a0OouV2PWiUtK6B8V8QHxeDBw1LNUDz5xpreekQ3tWwg@mail.gmail.com обсуждение исходный текст |
Ответ на | Speed-up shared buffers prewarming (Konstantin Knizhnik <knizhnik@garret.ru>) |
Список | pgsql-hackers |
On Wed, Mar 15, 2023 at 4:38 PM Konstantin Knizhnik <knizhnik@garret.ru> wrote: > It is well known fact that queries using sequential scan can not be used to prewarm cache, because them are using ringbuffer > even if shared buffers are almost empty. > I have searched hackers archive but failed to find any discussion about it. > What are the drawbacks of using free buffers even with BAM_BULKREAD strategy? > I mean the following trivial patch: It has been brought up at least in 2014 [1] and 2020 [2] The part relevant to your patch is in the thread from 2020 here [3]. This quote in particular: > a) Don't evict buffers when falling off the ringbuffer as long as > there unused buffers on the freelist. Possibly just set their > usagecount to zero as long that is the case. > diff --git a/src/backend/storage/buffer/freelist.c b/src/backend/storage/buffer/freelist.c > index 6be80476db..243335d0e4 100644 > --- a/src/backend/storage/buffer/freelist.c > +++ b/src/backend/storage/buffer/freelist.c > @@ -208,8 +208,15 @@ StrategyGetBuffer(BufferAccessStrategy strategy, uint32 *buf_state) > /* > * If given a strategy object, see whether it can select a buffer. We > * assume strategy objects don't need buffer_strategy_lock. > */ > - if (strategy != NULL) > + if (strategy != NULL && StrategyControl->firstFreeBuffer < 0) > { > buf = GetBufferFromRing(strategy, buf_state); > if (buf != NULL) > > So if there are free buffers, then use normal buffer allocation instead of GetBufferFromRing. Similar to what you did. - Melanie [1] https://www.postgresql.org/message-id/flat/CAJRYxuL98fE_QN7McnCM5HUo8p9ceNJw%3D20GoN5NVdZdueJFqg%40mail.gmail.com [2] https://www.postgresql.org/message-id/flat/20200206040026.trjzsmdsbl4gu2b6%40alap3.anarazel.de [5] https://www.postgresql.org/message-id/20200206040026.trjzsmdsbl4gu2b6%40alap3.anarazel.de
В списке pgsql-hackers по дате отправления: