Re: Using read stream in autoprewarm
От | Nazir Bilal Yavuz |
---|---|
Тема | Re: Using read stream in autoprewarm |
Дата | |
Msg-id | CAN55FZ0kf0sseBqyS4VsXNzMZEPAMLapJK7askiOS5w8JuObQw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using read stream in autoprewarm ("Andrey M. Borodin" <x4mmm@yandex-team.ru>) |
Ответы |
Re: Using read stream in autoprewarm
|
Список | pgsql-hackers |
Hi, Thanks for looking into this! On Thu, 31 Oct 2024 at 21:18, Andrey M. Borodin <x4mmm@yandex-team.ru> wrote: > > > On 8 Aug 2024, at 11:32, Nazir Bilal Yavuz <byavuz81@gmail.com> wrote: > > > > Any feedback would be appreciated. > > I've took a look into the patch. It seems to me that you add new block numbers to the read stream until you have buffers.So when there are no more buffers you will still have some queued blocks. > Maybe can you change the logic so that number of free buffers must be enough to allocate all blocks in look-ahead distance? I see what you mean. When the have_free_buffer() function returns false in the callback, there are still queued blocks in the stream although there are no free buffers in the buffer pool. I think the best way to solve this is to get the number of free buffers in the buffer pool by 'BufferStrategyControl.lastFreeBuffer - BufferStrategyControl.firstFreeBuffer' and then compare it with 'stream->pending_read_nblocks'. When the 'stream->pending_read_nblocks == number_of_free_buffers_in_buffer_pool', end the stream. The problem with that is stream->pending_read_nblocks isn't public, also I am not sure whether 'BufferStrategyControl.lastFreeBuffer - BufferStrategyControl.firstFreeBuffer' is safe to use. -- Regards, Nazir Bilal Yavuz Microsoft
В списке pgsql-hackers по дате отправления: