I disagree with the point made in the article. The article mentions
that ‘prevents the kernel from reordering reads and writes to optimize
performance,’ which might be referring to the file system’s IO
scheduling and merging. However, this can be handled within the
database itself, where IO scheduling and merging can be done even
better.
Regarding ‘does not allow free memory to be used as kernel cache,’ I
believe the database itself should manage memory well, and most of the
memory should be managed by the database rather than handed over to
the operating system. Additionally, the database’s use of the page
cache should be restricted.
On Wed, Aug 21, 2024 at 12:55 AM Bruce Momjian <bruce@momjian.us> wrote:
>
> On Tue, Aug 20, 2024 at 04:46:54PM +0300, Heikki Linnakangas wrote:
> > There are pros and cons. With direct I/O, you cannot take advantage of the
> > kernel page cache anymore, so it becomes important to tune shared_buffers
> > more precisely. That's a downside: the system requires more tuning. For many
> > applications, squeezing the last ounce of performance just isn't that
> > important. There are also scaling issues with the Postgres buffer cache,
> > which might need to be addressed first.
> >
> > With double write buffering, there are also pros and cons. It also requires
> > careful tuning. And replaying WAL that contains full-page images can be much
> > faster, because you can write new page images "blindly" without reading the
> > old pages first. We have WAL prefetching now, which alleviates that, but
> > it's no panacea.
>
> 陈宗志, you mimght find this blog post helpful:
>
> https://momjian.us/main/blogs/pgblog/2017.html#June_5_2017
>
> --
> Bruce Momjian <bruce@momjian.us> https://momjian.us
> EDB https://enterprisedb.com
>
> Only you can decide what is important to you.
--
---
Blog: http://www.chenzongzhi.info
Twitter: https://twitter.com/baotiao
Git: https://github.com/baotiao
