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). > > 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 -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers