Hi
ZongZhi, Thanks for feedback.
I have read prior thread on this email, and know your settings, when did
the testing, checkpoint_timeout set to 30s is too small, it's not a
reasonable setting ,
the value of checkpoint_timeout is determined by shared_buffers and the
workload, in real product environment, we usually set it to 30min or
longer, even 1 hours, when the setting is correct, FPW will not be a
problem or issue.
other issue is introduced by double write that is the recovery procedure
and replications, it is not a small project.
if you really focus on the write or read latency, I would like to advice
you to take a look for OrioleDB storage engine, I believe that's the
correct direction. it is more efficient reads and writes, resolving many
known overheads and issues in PostgreSQL
Regards
Tony
On 2026/2/28 03:11, 陈宗志 wrote:
Hi Tony,
Personally believe that the Double Write is very smart for MySQL InnoDB,
but not a good ideal for Postgres, currently, WAL is the best solution
for Postgres,
maybe the next generation log system for Postgres could use OrioleDB's
storage engine.
Just to clarify from a technical perspective, both MySQL and PostgreSQL
use Write-Ahead Logging (WAL) as their fundamental transaction logging
mechanism, so there is no difference in that regard.
The comparison here is specifically between Full-Page Writes (FPW) and
the Double Write Buffer (DWB). Neither of these concepts conflicts with
or replaces the core WAL design. Instead, both are simply different
techniques implemented to solve the exact same issue: preventing torn
pages during a crash.
My proposal is aimed at discussing the performance tradeoffs and
implementation details between these two specific torn-page protection
mechanisms, rather than replacing WAL itself.
Regards,
Baotiao
