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

Besides, there's already a throttle built in using the PGSTAT_STAT_INTERVAL

Best regards,
Gurjeet Singh http://gurjeet.singh.im/

EDB www.EnterpriseDB.com <http://www.enterprisedb.com>

Reply via email to