Re: General DB Tuning - Mailing list pgsql-performance
From | Tom Arthurs |
---|---|
Subject | Re: General DB Tuning |
Date | |
Msg-id | 42D4621D.4060803@jobflash.com Whole thread Raw |
In response to | Re: General DB Tuning (Brent Henry <bh_pgperf@yahoo.com>) |
Responses |
Re: General DB Tuning
|
List | pgsql-performance |
we are using jdbc -- the "log_min_duration_statement = 3000 " statement works fine for me. Looks like there's no other work around for the bug(?). Not sure since I have no interest in logging a million statements a day, I only want to see the poorly performing hits. Brent Henry wrote: > Yes, that is exactly what I want to use! > > Unfortunately, it doesn't work if you access postgres > through a JDBC connection. I don't know why. I found > a posting from back in February which talks aobut this > a little: > > http://archives.postgresql.org/pgsql-admin/2005-02/msg00055.php > > But I can't find anywhere where someone has fixed it. > Am I the only one accessing postgres through JDBC? > > -Brent > > > --- Tom Arthurs <tarthurs@jobflash.com> wrote: > > >>I have this in my postgresql.conf file and it works >>fine (set the min to >>whatever you want to log) >>log_min_duration_statement = 3000 # -1 is disabled, >>in milliseconds. >> >>Another setting that might get what you want: >> >>#log_duration = false >> >>uncomment and change to true. >> >> From the docs: >> > > (http://www.postgresql.org/docs/8.0/interactive/runtime-config.html) > >> Causes the duration of every completed statement >>which satisfies >>log_statement to be logged. When using this option, >>if you are not using >>syslog, it is recommended that you log the PID or >>session ID using >>log_line_prefix so that you can link the statement >>to the duration using >>the process ID or session ID. The default is off. >>Only superusers can >>change this setting. >> >>Brent Henry wrote: >> >>>Help! After recently migrating to Postgres 8, >> >>I've >> >>>discovered to my horror that I can't determine >> >>which >> >>>queries are poorly performing anymore because the >>>logging has drastically changed and no longer >> >>shows >> >>>durations for anything done through JDBC. >>> >>>So I'm desperately trying to do performance tuning >> >>on >> >>>my servers and have no way to sort out which >>>statements are the slowest. >>> >>>Does anyone have any suggestions? How do you >>>determine what queries are behaving badly when you >>>can't get durations out of the logs? >>> >>>I have a perl script that analyzes the output from >>>Postgres 7 logs and it works great! But it relies >> >>on >> >>>the duration being there. >>> >>>I did some searches on postgresql.org mailing >> >>lists >> >>>and have seen a few people discussing this >> >>problem, >> >>>but noone seems to be too worried about it. Is >> >>there >> >>>a simple work-around? >>> >>>Sincerely, >>> >>>Brent >>> >>> >>> >>> >> >>____________________________________________________ >> >>>Sell on Yahoo! Auctions – no fees. Bid on great >> >>items. >> >>>http://auctions.yahoo.com/ >>> >>>---------------------------(end of >> >>broadcast)--------------------------- >> >>>TIP 5: don't forget to increase your free space >> >>map settings >> >>> >>> >>---------------------------(end of >>broadcast)--------------------------- >>TIP 2: Don't 'kill -9' the postmaster >> > > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > ---------------------------(end of broadcast)--------------------------- > TIP 6: explain analyze is your friend > > >
pgsql-performance by date: