FPW stats?
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t38642psql -h localhost -U postgresBuilt from patchset v1 (message #1), July 27, 2026 at 08:31 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t38642_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t38642_1 && git checkout t38642_1Patchset v1 (message #1) is on t38642_1
Hi,
Recently I've heard people complaining that Postgres doesn't expose any
statistics about how many full page writes happened during some time frame.
Indeed, I couldn't find any easy way to do so, and judging from my
understanding of xloginsert.c it actually can be done per database with the
attached poc patch.
I guess it can be implemented in a more effective and optimized way, but with
what I have right now first naive pgbench tests show that slowdown is about 3%.
Before I'll dig into it more, it would be nice to hear your opinion about this
idea - does it make sense to have something like this?
On Wed, May 02, 2018 at 12:22:34PM +0200, Dmitry Dolgov wrote:
Recently I've heard people complaining that Postgres doesn't expose any
statistics about how many full page writes happened during some time
frame.
pg_waldump --stats?
I guess it can be implemented in a more effective and optimized way, but with
what I have right now first naive pgbench tests show that slowdown is about 3%.
Before I'll dig into it more, it would be nice to hear your opinion about this
idea - does it make sense to have something like this?
The bar to add new fields into pgstat structures is usually quite high
depending on the location where those are added. For example not so
long ago there was a patch discussed about adding more fields to
PgStat_StatTabEntry, which has been rejected as pgstat can be a problem
for users with many tables. See here:
/messages/by-id/1323.1511624064@sss.pgh.pa.us
Your patch adds a new field to PgStat_StatDBEntry? Wouldn't you
increase the bottleneck of deployments with many databases? What's
actually your use case?
--
Michael
On 2 May 2018 at 13:10, Michael Paquier <michael@paquier.xyz> wrote:
On Wed, May 02, 2018 at 12:22:34PM +0200, Dmitry Dolgov wrote:Recently I've heard people complaining that Postgres doesn't expose any
statistics about how many full page writes happened during some time
frame.pg_waldump --stats?
Yep, pg_waldump is the only option so far, but I thought about something that
will directly expose this info.
The bar to add new fields into pgstat structures is usually quite high
depending on the location where those are added. For example not so
long ago there was a patch discussed about adding more fields to
PgStat_StatTabEntry, which has been rejected as pgstat can be a problem
for users with many tables. See here:
/messages/by-id/1323.1511624064@sss.pgh.pa.usYour patch adds a new field to PgStat_StatDBEntry? Wouldn't you
increase the bottleneck of deployments with many databases? What's
actually your use case?
This was discussed mostly in the context of benchmarking and understanding IO
for different workloads. I actually never realized that adding a new stats
field can have significant impact in those cases when there are too many
databases, and yeah, I'm afraid it may be not justified in this context.
On Wed, May 2, 2018 at 7:10 AM, Michael Paquier <michael@paquier.xyz> wrote:
Your patch adds a new field to PgStat_StatDBEntry? Wouldn't you
increase the bottleneck of deployments with many databases? What's
actually your use case?
I'm a little doubtful about whether this particular thing is generally
useful but I think the bar for adding a field to PgStat_StatDBEntry is
probably a lot lower than for a per-table counter. I think adding
table-level counters is basically not happening without some kind of
rework of the infrastructure; whereas adding db-level counters seems
like it might be OK if we were convinced that they had real value.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company