On 8/22/24 10:50 AM, 陈宗志 wrote:
> 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.
The database does not have all the information that the OS has, but that
said I suspect that the advantages of direct IO outweigh the
disadvantages in this regard. But the only way to know for sure would be
fore someone to provide a benchmark.
> 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.
That all depends on you use case. If the database is running alone or
almost alone on a machine direct IO is likely the optional strategy but
if more services are running on the same machine (e.g. if you run
PostgreSQL on your personal laptop) you want to use buffered IO.
But as far as I know the long term plan of the async IO project is to
support both direct and buffered IO so people can pick the right choice
for their workload.
Andreas
