Jim Nasby <jim.na...@bluetreble.com> writes:
> On 11/10/14, 12:56 PM, Andres Freund wrote:
>> If you want to do this - and I sure don't want to stop you from it - you
>> should look at it from a general perspective, not from the perspective
>> of how skipped cleanup locks are logged.
> Honestly, my desire at this point is just to see if there's actually a
> problem. Many people are asserting that this should be a very rare
> occurrence, but there's no way to know.
> Towards that simple end, I'm a bit torn. My preference would be to simply
> log, and throw a warning if it's over some threshold. I believe that would
> give the best odds of getting feedback from users if this isn't as uncommon
> as we think.
> I agree that ideally this would be tracked as another stat, but from that
> standpoint I think there's other, much more important metrics to track, and
> AFAIK the only reason we don't have them is that busy systems already push
> pgstats to it's limits. We should try and fix that, but that's a much bigger
> issue.
Yeah. We know that per-table pgstat counters are a pretty expensive thing
in databases with many tables. We should absolutely not be adding them on
mere speculation that the number might be interesting.
Now, that objection would not apply to a per *database* counter, but I'm
not sure if tracking the numbers at that granularity would help anyone.
On the whole, I'm +1 for just logging the events and seeing what we learn
that way. That seems like an appropriate amount of effort for finding out
whether there is really an issue.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
