Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal
| От | Michael Paquier |
|---|---|
| Тема | Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal |
| Дата | |
| Msg-id | aPiZdu_jqEl2w1FN@paquier.xyz обсуждение исходный текст |
| Ответ на | Add wal_fpi_bytes_[un]compressed to pg_stat_wal (Shinya Kato <shinya11.kato@gmail.com>) |
| Ответы |
Re: Add wal_fpi_bytes_[un]compressed to pg_stat_wal
|
| Список | pgsql-hackers |
On Wed, Oct 22, 2025 at 05:04:58PM +0900, Shinya Kato wrote: > The 0001 patch adds these columns to pg_stat_wal. The 0002 and 0003 > patches add this information to EXPLAIN (WAL) and pg_stat_statements, > respectively. I don't think these additions (0002 and 0003) are > mandatory, so I suggest we focus the discussion on the 0001 patch > first. We already know the number of FPIs generated. Hence my take would be to use only one counter, not two: an aggregated FPI length like in xlogstats.h as exposed in pg_walinspect. That should be enough to offer trends regarding the effects of compression, even if some pages have holes that are discarded. > Thoughts? I would suggest to leave PGSS out of it for now. We really need to do something about the number of fields computed, with more GUCs to disable groups of them, at least, like JIT or the planning parts. No objections for the EXPLAIN and pg_stat_wal parts. The patch can be simpler. There is no need to pass the calculated number(s) across multiple functions in the stack, you can just aggregate the numbers in pgWalUsage directly in XLogRecordAssemble(). The only extra thing to do is that one needs to set pgstat_report_fixed to true to force the report to pgstats. -- Michael
Вложения
В списке pgsql-hackers по дате отправления: