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
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 schedul
For other approaches, such as whether to use an LRU list to manage the
shared_buffer or to use a clock sweep for management, both methods
have their pros and cons. But for these two issues, there is a clearly
better solution. For example, using DirectIO avoids the problem of
double-copying data, an
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
On 20/08/2024 11:46, 陈宗志 wrote:
I’ve recently started exploring PostgreSQL implementation. I used to
be a MySQL InnoDB developer, and I find the PostgreSQL community feels
a bit strange.
There are some areas where they’ve done really well, but there are
also some obvious issues that haven’t been
On Tue, Aug 20, 2024 at 8:55 PM 陈宗志 wrote:
> It seems like these issues have clear solutions, such as using
> DirectIO like InnoDB instead of buffered IO,
For this part: we recently added an experimental option to use direct
I/O (debug_io_direct). We are working on the infrastructure needed to
m
