"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
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 volu
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 =
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 bi
"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 remo
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 shou
"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_quer
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 statem
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 calculat
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 calculat
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
"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 U
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 lo
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
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
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
---
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 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 tha
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 g
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, an
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
slow
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
dura
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
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 hosti
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 t
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
"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 ---
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 t
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
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 dum
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 ab
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
""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 gu
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 million
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 a
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 eleme
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
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
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 t
> 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_me
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 m
> 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 th
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 log_long
> 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.
>
> > 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 lo
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
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 logg
"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 m
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 queri
49 matches
Mail list logo
