Re: Patch to send transaction commit/rollback stats to the stats collector unconditionally.

On Wed, Mar 19, 2014 at 7:27 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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>