On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Alvaro Herrera <alvhe...@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. Best regards, -- Gurjeet Singh http://gurjeet.singh.im/ EDB www.EnterpriseDB.com <http://www.enterprisedb.com>
