On Friday 15 June 2007 13:29, Greg Smith wrote:
> On Fri, 15 Jun 2007, Umar Farooq wrote:
> > Surprisingly, no matter what type of query I execute, when I use strace
> > to monitor the system calls generated they turn out to be the same for
> > ALL sorts of queries.
>
> How are you calling strace?
On Fri, 15 Jun 2007, Umar Farooq wrote:
Surprisingly, no matter what type of query I execute, when I use strace
to monitor the system calls generated they turn out to be the same for
ALL sorts of queries.
How are you calling strace? The master postgres progress forks off new
processes for e
Hello All,Recently, I have been involved in some work that requires me to
monitor low level performance counters for pgsql. Specifically, when I execute
a particular query I want to be able to tell how many system calls get executed
on behalf of that query and time of each sys call. The idea is
Heikki Linnakangas napsal(a):
Jim C. Nasby wrote:
There is two counters for checkpoints in pgstats, the number of timed
(triggered by checkpoint_timeout) and requested (triggered by
checkpoint_segments) checkpoints.
Maybe we should improve the stats system so that we can collect events
w
On Sun, May 13, 2007 at 07:54:20AM +0100, Heikki Linnakangas wrote:
> Maybe we should improve the stats system so that we can collect events
> with timestamps and durations, but in my experience log files actually
> are the most reliable and universal way to collect real-time performance
> infor
Heikki Linnakangas wrote:
>>> Yeah, if we have the summary line we don't need the other lines and
>>> vice versa. I have sympathy for parsing log files, I've done that a
>>> lot in the past and I can see what you mean. Having the individual
>>> lines is nice when you're monitoring a running system;
Jim C. Nasby wrote:
Moving to -hackers.
On Fri, May 11, 2007 at 04:37:44PM +0100, Heikki Linnakangas wrote:
If you know when the checkpoint ended, and you know how long each of the
pieces took, you can reconstruct the other times easily. The way you
describe this it is true--that the summary
On Sat, 2007-12-05 at 14:26 -0700, Joshua D. Drake wrote:
> Either way, we are taking the hit, it is just a matter of where. IMO it
> would be better to have the information in the database where it makes
> sense, than pushing out to a log
If performance monitoring information is provided as a d
On Sat, 12 May 2007, Joshua D. Drake wrote:
One thing that doesn't seemed to be being looked at it is the cost of
logging.
If any of this executed at something like the query level, sure, that
would be real important. The majority of the logging I suggested here is
of things that happen at
Not to beat a dead horse, but do we really want to force folks to be
parsing logs for performance monitoring? Especially if that log parsing
is just going to result in data being inserted into a table anyway?
I know there's concern about performance of the stats system and maybe
that needs to b
Moving to -hackers.
On Fri, May 11, 2007 at 04:37:44PM +0100, Heikki Linnakangas wrote:
> >If you know when the checkpoint ended, and you know how long each of the
> >pieces took, you can reconstruct the other times easily. The way you
> >describe this it is true--that the summary is redundant
11 matches
Mail list logo
