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.)
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: