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,
29 matches
Mail list logo
