On 9/16/06, Alvaro Herrera [EMAIL PROTECTED] wrote:
It might make sense to log _what_ is going on, without telling all the
little details, for example
LOG: parse duration: 0.250 ms
LOG: bind duration: 0.057 ms
LOG: execute my_query: SELECT * FROM shop WHERE $1 = $2
DETAIL: parameters: $1 =
On 9/16/06, Tom Lane [EMAIL PROTECTED] wrote:
The only asymmetry in the thing is that if log_statement fired then
we suppress duplicate printing of the query in the later duration log
message (if any) for that query. But that seems like the right thing
if you're at all concerned about log
Guillaume Smet [EMAIL PROTECTED] writes:
My only concern was that we now have less information with
log_statement='all' than with log_min_duration_statement.
Well, you don't have the durations, but log_statement isn't supposed to
tell you that. So I'm still quite confused about what it is that
On 9/8/06, Tom Lane [EMAIL PROTECTED] wrote:
It's done already ...
(Working on implementing the last changes you made in formatting in pgFouine)
Is it normal that when I set log_duration to on and log_statement to
all, I have the following output when I prepare/bind/execute a
prepared
Guillaume Smet [EMAIL PROTECTED] writes:
Is it normal that when I set log_duration to on and log_statement to
all, I have the following output when I prepare/bind/execute a
prepared statement using the protocol:
LOG: duration: 0.250 ms
LOG: duration: 0.057 ms
LOG: execute my_query: SELECT
On 9/16/06, Tom Lane [EMAIL PROTECTED] wrote:
Well, considering that the parse and bind may take longer than the
execute, I hardly think we want to ignore them for log_duration
purposes. And we agreed that if log_duration is on and
log_min_duration_statement is not triggered, log_duration
Guillaume Smet [EMAIL PROTECTED] writes:
If we consider that the prepare and the bind operations are important
(and I agree they can be), I wonder why do we remove the output we
have when log_min_duration_statement is set to 0 (I'm thinking of the
parse: and bind: lines)?
Well, we remove it
Tom Lane wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
If we consider that the prepare and the bind operations are important
(and I agree they can be), I wonder why do we remove the output we
have when log_min_duration_statement is set to 0 (I'm thinking of the
parse: and bind: lines)?
Alvaro Herrera wrote:
Bruce Momjian wrote:
#2, I think, but I am confused if you don't know the query, how
valuable is the log_duration.
Statistics?
I doubt that there is a statistical merit to calculating aggregate
values over the duration of an anonymous set of queries.
--
Peter
On Sat, Sep 09, 2006 at 06:33:10PM +0200, Peter Eisentraut wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
#2, I think, but I am confused if you don't know the query, how
valuable is the log_duration.
Statistics?
I doubt that there is a statistical merit to calculating aggregate
On Sat, Sep 09, 2006 at 06:33:10PM +0200, Peter Eisentraut wrote:
Alvaro Herrera wrote:
Bruce Momjian wrote:
#2, I think, but I am confused if you don't know the query, how
valuable is the log_duration.
Statistics?
I doubt that there is a statistical merit to calculating aggregate
On 9/8/06, Bruce Momjian [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
Statistics?
Oh, interesting.
We build this type of report for our customers:
http://pgfouine.projects.postgresql.org/reports/sample_hourly.html
This one is a real one.
As you can see, we cannot tell the type of every
Tom,
On 9/8/06, Tom Lane [EMAIL PROTECTED] wrote:
It seems like we should either remove the separate log_duration boolean
or make it work as he suggests. I'm leaning to the second answer now.
Do you want me to propose a patch or do you prefer to work on it
yourself? If so, do we keep the
Guillaume Smet [EMAIL PROTECTED] writes:
Do you want me to propose a patch or do you prefer to work on it
yourself?
It's done already ...
regards, tom lane
---(end of broadcast)---
TIP 1: if posting/reading through
AFAICS, there is absolutely no difference anymore between turning
log_duration ON and setting log_min_duration_statement to zero.
ISTM that having the two redundant GUC settings is just confusing,
and we should remove log_duration to simplify things.
regards, tom lane
Tom,
On 9/7/06, Tom Lane [EMAIL PROTECTED] wrote:
AFAICS, there is absolutely no difference anymore between turning
log_duration ON and setting log_min_duration_statement to zero.
ISTM that having the two redundant GUC settings is just confusing,
and we should remove log_duration to simplify
Guillaume Smet [EMAIL PROTECTED] writes:
I mean:
log_duration = on
log_min_duration_statement = 500
would log only duration for queries faster than 500 ms and duration +
query text for queries slower than 500ms (we can easily avoid
redundancy).
I don't find this very persuasive --- it
On Thu, Sep 07, 2006 at 06:06:51PM -0400, Tom Lane wrote:
Guillaume Smet [EMAIL PROTECTED] writes:
I mean:
log_duration = on
log_min_duration_statement = 500
would log only duration for queries faster than 500 ms and
duration + query text for queries slower than 500ms (we can easily
Tom,
I don't find this very persuasive --- it sounds awfully messy, and in
fact isn't that exactly the old behavior we got rid of because no one
could understand it?
Well, we want analogous functionality. We could stand to have it
named/organized differently. But maybe we should hold
On 9/8/06, Tom Lane [EMAIL PROTECTED] wrote:
I don't find this very persuasive --- it sounds awfully messy, and in
fact isn't that exactly the old behavior we got rid of because no one
could understand it?
I gave real use cases and we use it every day. It really helps us as a
PostgreSQL
Guillaume Smet wrote:
On 9/8/06, Tom Lane [EMAIL PROTECTED] wrote:
I don't find this very persuasive --- it sounds awfully messy, and in
fact isn't that exactly the old behavior we got rid of because no one
could understand it?
I gave real use cases and we use it every day. It really
Bruce Momjian [EMAIL PROTECTED] writes:
If you are using an external tool, can't you just restrict what you
display based on the logged duration?
I think his basic complaint is that doing the full logging pushup for
even short-duration queries is too expensive, and that logging only the
On 9/8/06, Bruce Momjian [EMAIL PROTECTED] wrote:
If you are using an external tool, can't you just restrict what you
display based on the logged duration?
It's not a matter of having too much information in our reports (the
more information I have, the happier I am :)). It's a matter of
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
If you are using an external tool, can't you just restrict what you
display based on the logged duration?
I think his basic complaint is that doing the full logging pushup for
even short-duration queries is too expensive, and that
Bruce Momjian [EMAIL PROTECTED] writes:
Well, except for bind, all the log output display is zero cost, just a
printf(), as I remember. The only cost that is significant, I think, is
the timing of the query, and that is happening for all the setttings
discussed.
On a machine with slow
On 9/8/06, Tom Lane [EMAIL PROTECTED] wrote:
I think his basic complaint is that doing the full logging pushup for
even short-duration queries is too expensive, and that logging only the
duration and not the query text or parameters makes a significant speed
difference. I'm not at all sure that
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
Well, except for bind, all the log output display is zero cost, just a
printf(), as I remember. The only cost that is significant, I think, is
the timing of the query, and that is happening for all the setttings
discussed.
On a
Bruce Momjian wrote:
#2, I think, but I am confused if you don't know the query, how valuable
is the log_duration.
Statistics?
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Alvaro Herrera wrote:
Bruce Momjian wrote:
#2, I think, but I am confused if you don't know the query, how valuable
is the log_duration.
Statistics?
Oh, interesting.
--
Bruce Momjian [EMAIL PROTECTED]
EnterpriseDBhttp://www.enterprisedb.com
+ If your life is a hard drive,
On Mon, 2006-03-13 at 23:40 +0100, Guillaume Smet wrote:
Here are some background information to explain our issue and request.
We are currently planning a migration from PostgreSQL 7.4 to
PostgreSQL 8.1. We work on a medium sized database (2GB) with a rather
important activity (12 millions
Guillaume Smet [EMAIL PROTECTED] wrote
Here are some background information to explain our issue and request.
On a separate issue, seems in pgfouine homepage a typo is there for a while:
What's New
2005-02-11 - pgFouine 0.4.99 released ...
2005-01-10 - pgFouine 0.2.1 released ...
I guess
On 3/14/06, Qingqing Zhou [EMAIL PROTECTED] wrote:
I guess they should read as 2006 :-)
Sure. Will fix it this evening. Thanks.
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
Simon,
On 3/14/06, Simon Riggs [EMAIL PROTECTED] wrote:
Thanks very much for writing pgFouine. We've been doing our best to
support generation of useful logs for performance analysis, so please
feel free to ask for anything you see a need for.
OK. Thanks. I should write something clear about
On Tue, Mar 14, 2006 at 08:50:22AM +, 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
Hello,
Here are some background information to explain our issue and request.
We are currently planning a migration from PostgreSQL 7.4 to
PostgreSQL 8.1. We work on a medium sized database (2GB) with a rather
important activity (12 millions queries a day with peaks up to 1000
queries/s).
We are
Added to TODO:
* Add GUC log_statement_duration to print statement and = min duration
---
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One nice thing is that each element is
Christopher Kings-Lynne wrote:
Someone asked about this at FOSDEM. The only way I know to do it is look
in the pgsql_temp directory, but they disappear pretty quickly. Folks,
do we need something to report sort file usage?
Fwiw here's the perl one-liner I used to tune sort_mem
Greg Stark wrote:
Not a big deal though, since I doubt anyone's actually parsing
postgres logs. Hm, brings up an interesting idea though, I wonder
if it would be useful to log directly into postgres tables.
I was wondering roughly the same thing. If you ran an external
program to process the
Bruce Momjian [EMAIL PROTECTED] writes:
One nice thing is that each element is orthoginal. But, for the
functionality desired, we have to merge log_statement and log_duration
and have it print for statements taking over X milliseconds. I have no
problem adding it, but it has to be clear it
One option is to have log_query output an identifier with the query such as a
hash of the query or the pointer value for the plan, suppressing duplicates.
Then log_duration prints the identifier with the duration.
Actually, log_pid is the proper way to do this. You can then add log
Greg Stark wrote:
Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Looking at the log_duration postgresql.conf option. How about adding an
option log_duration_min which is a value in milliseconds that is the minimum
time a query must run for
Tom is right here. log_duration _just_ prints the duration, so we would
need to basically create a merged param that does log_duration and
log_statement and have it activate only if the statement takes more than
X milliseconds, something like log_long_statement, or something like
that.
Christopher Kings-Lynne wrote:
Tom is right here. log_duration _just_ prints the duration, so we would
need to basically create a merged param that does log_duration and
log_statement and have it activate only if the statement takes more than
X milliseconds, something like
Someone asked about this at FOSDEM. The only way I know to do it is look
in the pgsql_temp directory, but they disappear pretty quickly. Folks,
do we need something to report sort file usage?
How about a new GUC variable: log_sort_tempfiles
And in the code that creates the temp file, if the
Well, part of the issue here is that it isn't always bad to use sort
file; certainly it is better to use them than to swap.
We have a checkpoint_warning in 7.4 that will warn about excessive
checkpointing. What would our criteria be for warning about sort_mem?
Seems we would have to know how
Tom Lane wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
One nice thing is that each element is orthoginal. But, for the
functionality desired, we have to merge log_statement and log_duration
and have it print for statements taking over X milliseconds. I have no
problem adding it, but it
Tom Lane [EMAIL PROTECTED] writes:
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Looking at the log_duration postgresql.conf option. How about adding an
option log_duration_min which is a value in milliseconds that is the minimum
time a query must run for before being logged.
Fine
Hi guys,
Looking at the log_duration postgresql.conf option. How about adding an
option log_duration_min which is a value in milliseconds that is the minimum
time a query must run for before being logged. Basically, what I'd be
interested in is please log the SQL query and duration of all
Christopher Kings-Lynne [EMAIL PROTECTED] writes:
Looking at the log_duration postgresql.conf option. How about adding an
option log_duration_min which is a value in milliseconds that is the minimum
time a query must run for before being logged.
Fine with me --- but you'll need to add more
49 matches
Mail list logo
