Re: log_duration and log_statement

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Simon Riggs <simon(at)2ndquadrant(dot)com>
Cc: Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: log_duration and log_statement
Date: 2006-03-14 19:13:23
Message-ID: 20060314191323.GM45250@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Mar 14, 2006 at 08:50:22AM +0000, Simon Riggs wrote:
> Is the issue that the log volume is too high? We might be able to look
> at ways to reduce/compress the log volume for duration/statement
> logging.

ISTM that for performance analysis there's probably a better alternative
than just dumping query statements to a logfile. The information we
really want is stuff like:

WAL sync's per second
Read-only queries per second
Queries that modify data per second
Transactions per second
Blacks written per second (maybe broken down by WAL, heap and index)
etc...

Doesn't really have anything to do with logging query strings passed
into the parser.

I know dtrace could be used to provide this kind of info, but it's only
on Solaris (and eventually FreeBSD). But it should be possible to
provide our own version of that for platforms that don't have something
like dtrace.

Or perhaps there's some entirely different statistics collection method
we could come up with...
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-03-14 19:29:20 Re: Restoring a Full Cluster on a Different Architecture (32 x 64)
Previous Message Jonah H. Harris 2006-03-14 19:12:39 Re: Restoring a Full Cluster on a Different Architecture (32 x 64)