| From: | shihao zhong <zhong950419(at)gmail(dot)com> |
|---|---|
| To: | Jeremy Schneider <schneider(at)ardentperf(dot)com> |
| Cc: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Lakshmi N <lakshmin(dot)jhs(at)gmail(dot)com>, Tomas Vondra <tomas(at)vondra(dot)me> |
| Subject: | Re: Skip prefetch for block references that follow a FPW or WILL_INIT of the same block |
| Date: | 2026-10-27 14:24:05 |
| Message-ID: | CAGRkXqRu3vGy52-=4Gi-rxMV79YSbZToM2f_6otFUnx=QEMcVQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Jeremy,
I think I missed reading your github link yesterday night. I agree it shows
IOPS difference between primary and replica.
After digging in a bit more (thanks to your blog[1]), I noticed the current
prefetcher
always calls FADVISE before pread, which looks like bypass OS readahead for
sequential access.
In the replay path, this may happen right after the primary finishes a
large
sequential write (e.g., vacuum or a full-table update). But I am not sure
if these workload are
common because most of the time vacuum can skip pages and the write is not
purely
sequential and full-table update is not that common as well.
But I agree this is a problem we need to fix.
> This is exactly the problem. Because of that ratio.....
I think repeated fadvise calls on continuous blocks would not trigger OS
prefetch and we'd be turning
sequential I/O into random I/O, burning more IOPS while leaving bandwidth
underutilized.....
[1]
https://ardentperf.com/2026/10/20/postgres-recovery_prefetch-considered-harmful-and-causing-outages/
Thanks,
Shihao
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tomas Vondra | 2026-10-27 14:26:23 | Re: Skip prefetch for block references that follow a FPW or WILL_INIT of the same block |
| Previous Message | Jim Jones | 2026-10-27 14:05:29 | Re: Reject incompatible options specified with VACUUM ONLY_DATABASE_STATS |