Re: Streaming I/O, vectored I/O (WIP)
От | Thomas Munro |
---|---|
Тема | Re: Streaming I/O, vectored I/O (WIP) |
Дата | |
Msg-id | CA+hUKGJp2teTX3FAE9S3DQij0cK2GKzOjn7nfag0g3JbabiyvQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Streaming I/O, vectored I/O (WIP) (Thomas Munro <thomas.munro@gmail.com>) |
Список | pgsql-hackers |
On Thu, Mar 28, 2024 at 2:02 PM Thomas Munro <thomas.munro@gmail.com> wrote: > ... In practice on a non-toy system, that's always going to be > io_combine_limit. ... And to be more explicit about that: you're right that we initialise max_pinned_buffers such that it's usually at least io_combine_limit, but then if you have a very small buffer pool it gets clobbered back down again by LimitAdditionalBins() and may finish up as low as 1. You're not allowed to pin more than 1/Nth of the whole buffer pool, where N is approximately max connections (well it's not exactly that but that's the general idea). So it's a degenerate case, but it can happen that max_pinned_buffers is lower than io_combine_limit and then it's important not to set distance higher or you'd exceed the allowed limits (or more likely the circular data structure would implode).
В списке pgsql-hackers по дате отправления: