Skip site navigation (1) Skip section navigation (2)

Re: RFC: Timing Events

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: RFC: Timing Events
Date: 2012-11-03 01:44:25
Message-ID: 509476F9.7040202@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-hackers
> I don't see all that going into core without a much bigger push than I
> think people will buy.  What people really want for all these is a
> proper trending system, and that means graphs and dashboards and
> bling--not a history table.

Well, I'm particularly thinking for autoconfiguration.  For example, to
set vacuum_freeze_min_age properly, you have to know the XID "burn rate"
of the server, which is only available via history.  I really don't want
to be depending on a graphical monitoring utility to find these things out.

> This whole approach has the assumption that things are going to fall off
> sometimes.  To expand on that theme for a second, right now I'm more
> worried about the "99%" class of problems.  Neither pg_stat_statements
> nor this idea are very good for tracking the rare rogue problem down.
> They're both aimed to make things that happen a lot more statistically
> likely to be seen, by giving an easier UI to glare at them frequently.
> That's not ideal, but I suspect really fleshing the whole queue consumer
> -> table idea needs to happen to do much better.

I'm just concerned that for some types of incidents, it would be much
more than 1% *of what you want to look at* which fall off.  For example,
consider a server which does 95% reads at a very high rate, but has 2%
of its writes cronically having lock waits.  That's something you want
to solve, but it seems fairly probably that these relatively infrequent
queries would have fallen off the bottom of pg_stat_statements.  Same
thing with the relative handful of queries which do large on-disk sorts.

The problem I'm worried about is that pg_stat_statements is designed to
keep the most frequent queries, but sometimes the thing you really need
to look at is not in the list of most frequent queries.

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com


In response to

Responses

pgsql-hackers by date

Next:From: Nikhil SontakkeDate: 2012-11-03 04:51:22
Subject: Re: Bug in ALTER COLUMN SET DATA TYPE ?
Previous:From: Josh BerkusDate: 2012-11-03 01:38:49
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group