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).
>
> 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?
> That is, even granting that anybody has a workload that acts like this,
> why would they care ... and are they prepared to take a performance hit
> to avoid the counter jump after the monitoring app exits?

Well, EnterpriseDB has a monitoring product called Postgres Enterprise
Manager (PEM) that sits around and does stuff like periodically
reading statistics views. I think you can probably configure it to
read from regular tables too, but it's hardly insane that someone
would have a long-running monitoring connection that only reads
statistics and monitoring views.

(This is not a vote for or against the patch, which I have not read.
It's just an observation.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company