Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal
| От | Shinya Kato | 
|---|---|
| Тема | Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal | 
| Дата | |
| Msg-id | CAOzEurSiSr+rusd0GzVy8Bt30QwLTK=ugVMnF6=5WhsSrukvvw@mail.gmail.com обсуждение исходный текст  | 
		
| Ответ на | Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal (Michael Paquier <michael@paquier.xyz>) | 
| Ответы | 
                	
            		Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal
            		
            		 | 
		
| Список | pgsql-hackers | 
On Tue, Oct 28, 2025 at 4:32 PM Michael Paquier <michael@paquier.xyz> wrote: > Without the changes in instrument.c from patch 0002, patch 0001 that > implements the basics would not work. So.. I have moved the changes > of instrument.c to 0001, reordered the fields to be more consistent, > did two bumps (catalog, stats file), simplified the docs, then applied > the result. Sorry for the inconvenience, and thank you for committing. I have revised patch 0002, which adds wal_fpi_bytes to EXPLAIN (WAL). > By the way, Kato-san, what do you think about the attached extra > simplification? With the FPIs counted in bytes, I don't see much a > point in passing around the number of FPIs generated from > XLogRecordAssemble() to XLogInsertRecord() . I investigated previous discussions and found [0]. This thread mentioned that XLogInsert() calls XLogRecordAssemble() multiple times in its do-while loop, so the value might be invalid. Based on the discussion above, it seems my previous patch also has the same issue. [0] https://www.postgresql.org/message-id/20200329121944.GA79261%40nol -- Best regards, Shinya Kato NTT OSS Center
Вложения
В списке pgsql-hackers по дате отправления: