| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: Streaming I/O, vectored I/O (WIP) |
| Date: | 2024-03-28 01:20:38 |
| Message-ID: | CA+hUKGJp2teTX3FAE9S3DQij0cK2GKzOjn7nfag0g3JbabiyvQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Mar 28, 2024 at 2:02 PM Thomas Munro <thomas(dot)munro(at)gmail(dot)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).
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2024-03-28 01:20:50 | Re: POC PATCH: copy from ... exceptions to: (was Re: VLDB Features) |
| Previous Message | Thomas Munro | 2024-03-28 01:02:38 | Re: Streaming I/O, vectored I/O (WIP) |