Re: suggestion: log_statement = sample - Mailing list pgsql-general

From Bill Moran
Subject Re: suggestion: log_statement = sample
Date
Msg-id 20090716090558.d9292283.wmoran@potentialtech.com
Whole thread Raw
In response to suggestion: log_statement = sample  (Janning Vygen <vygen@kicktipp.de>)
Responses Re: suggestion: log_statement = sample
List pgsql-general
In response to Janning Vygen <vygen@kicktipp.de>:

> hi,
>
> http://archives.postgresql.org/pgsql-general/2009-03/msg00581.php
>
> This was my suggestion about introducing a statment to get a sample of SQL
> statements. Nobody answered yet. Why not? i think my suggestion would help a
> lot. Or was it kind of stupid?

For my part, I don't think this would be useful.

Since most of your queries are run by software, you're going to see a
fairly predictable pattern to the queries, which means your sampling isn't
going to be anywhere near random, thus it will still be inaccurate and
incomplete.

In my experience, I've found that enabling full logging for a short time
(perhaps a few hours) gathers enough data to run through tools like
pgFouine and find problem areas.  Also, we have development servers that
run automated tests, and since it's not critical that they be performant,
we can run full query logging on them all the time.  Additionally, we make
sure our production systems have enough hardware behind them that we can
add additional tasks without it affecting production use.

All of these are (in my opinion) better approaches to the problem than
yet another arbitrary query filtering technique.  I mean, logging only
the most time-consuming queries is already arbitrary enough (as you
already stated).

--
Bill Moran
http://www.potentialtech.com
http://people.collaborativefusion.com/~wmoran/

pgsql-general by date:

Previous
From: Rafael Martinez
Date:
Subject: Re: Problems with 8.4, FLOAT8PASSBYVAL and x86_64 GNU/Linux
Next
From: "Albe Laurenz"
Date:
Subject: Re: Working around spurious unique constraint errors due to SERIALIZABLE bug