Comments on End Point Blog: Announcing Release of PostgreSQL System Impact (PG...

In at least one place that we are using PGSI, we h...

2009-02-24T11:58:00.000-05:00

In at least one place that we are using PGSI, we have commented out one of rsyslog's default options:

"RSYSLOG_TraditionalFileFormat"

This option makes rsyslog use "traditional" timestamps. We wanted the more verbose timestamp that rsyslog uses when it is not told otherwise. This may be your issue, Denis.

This was designed for use with [r]syslog, and the ...

2009-02-24T10:13:00.000-05:00

This was designed for use with [r]syslog, and the log files look like this (all one line):

2009-02-24T08:09:29-07:00 hostname postgres[11902]: [130-1] LOG: statement: DEALLOCATE dbdpg_13

As far as I know, there is no special syslog.conf or rsyslog.conf setting as to the output format.

The test suite that comes with it has a log_line_prefix that is used to emulate syslog's output, as doing unit tests with syslog is a whole lot tricker than just using a log file you can control.

Any chance you could post the relevant logging con...

2009-02-23T10:03:00.000-05:00

Any chance you could post the relevant logging configuration bits from a server that does output the correct format? I have tried PGSI on a couple of servers now and none matched properly..

This does sound like a terriffic tool!

Are there any other settings that we need to do...

2009-02-15T13:09:00.000-05:00
Are there any other settings that we need to do in postgresql.conf other than setting log_duration, log_statement and log_destination?

Also, anything else we need to do on (r)syslog.conf?

The code does require a specific format for the log entries, which is specified in the docs.

%Y-%m-%dT%H:%M:%S(%:z)? server postgres[pid]:

Are there any other settings that we need to do in...

2009-02-14T18:44:00.000-05:00
Are there any other settings that we need to do in postgresql.conf other than setting log_duration, log_statement and log_destination?

Also, anything else we need to do on (r)syslog.conf?

While the actual system impact number does not ...

2009-02-14T17:05:00.000-05:00
While the actual system impact number does not (to my knowledge) have any kind of absolute meaning, the relative values of the queries analyzed makes the offenders stick out clearly.

It does have a specific meaning. SI indicates the number of instances of the given query that, on average, are running over the interval at any given moment. The simplest example is a SI of 100. This means that exactly 1 instance of this query is running over the interval at all times, on average. SI=200 -> 2 instances at all times, on average.

Thinking of it as a percentage tends to be more useful, I think, for other values. That is, SI of 80 means 0.8 instance of the query running at all times (which never would actually be true since you can't have non-integer instances of a query running), but you can think of it instead as 1 instance of the query running 80% of the time over the interval.

Yay!

This is a terrific tool. The balance ...

2009-02-14T16:38:00.000-05:00
Yay!

This is a terrific tool. The balance of query runtime versus execution frequency is something that can easily elude the engineer when trying to identify low-hanging optimization fruit. While the actual system impact number does not (to my knowledge) have any kind of absolute meaning, the relative values of the queries analyzed makes the offenders stick out clearly.

Thanks for getting it out there, Mark.

Comments on End Point Blog: Announcing Release of PostgreSQL System Impact (PG...

In at least one place that we are using PGSI, we h...

This was designed for use with [r]syslog, and the ...

Any chance you could post the relevant logging con...

Are there any other settings that we need to do...

Are there any other settings that we need to do in...

While the actual system impact number does not ...

Yay!This is a terrific tool. The balance ...

Yay!

This is a terrific tool. The balance ...