On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alvaro Herrera <alvherre@2ndquadrant.com> writes: > I'm not sure I understand the point of this whole thing. Realistically, > how many transactions are there that do not access any database tables?
I think that something like "select * from pg_stat_activity" might not bump any table-access counters, once the relevant syscache entries had gotten loaded. You could imagine that a monitoring app would do a long series of those and nothing else (whether any actually do or not is a different question).
+1. This is exactly what I was doing; querying pg_stat_database from a psql session, to track transaction counters.
But still, it's a bit hard to credit that this patch is solving any real problem. Where's the user complaints about the existing behavior?
Consider my original email a user complaint, albeit with a patch attached. I was trying to ascertain TPS on a customer's instance when I noticed this behaviour; it violated POLA. Had I not decided to dig through the code to find the source of this behaviour, as a regular user I would've reported this anomaly as a bug, or maybe turned a blind eye to it labeling it as a quirky behaviour.
That is, even granting that anybody has a workload that acts like this, why would they care ...
To avoid surprises!
This behaviour, at least in my case, causes Postgres to misreport the very thing I am trying to calculate.
and are they prepared to take a performance hit to avoid the counter jump after the monitoring app exits?
It doesn't look like we know how much of a performance hit this will cause. I don't see any reasons cited in the code, either. Could this be a case of premature optimization. The commit log shows that, during the overhaul (commit 77947c5), this check was put in place to emulate what the previous code did; code before that commit reported stats, including transaction stats, only if there were any regular or shared table stats to report.
Besides, there's already a throttle built in using the PGSTAT_STAT_INTERVAL limit.