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
