| From: | Ulrich Wisser <ulrich(dot)wisser(at)relevanttraffic(dot)se> | 
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org | 
| Cc: | bruno(at)wolff(dot)to | 
| Subject: | Re: [GENERAL] How to know which queries are to be optimised? | 
| Date: | 2004-08-12 10:37:44 | 
| Message-ID: | 411B4878.4090804@relevanttraffic.se | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-general pgsql-performance | 
Hi Bruno,
>>my web application grows slower and slower over time. After some 
>>profiling I came to the conclusion that my SQL queries are the biggest 
>>time spenders (25 seconds). Obviously I need to optimise my queries and 
>>maybe introduce some new indexes.
> 
> This sounds like you aren't doing proper maintainance. You need to be
> vacuuming with a large enough FSM setting.
I do a vacuum full analyze every night.
How can I see if my FSM setting is appropriate?
>>The problem is, that my application uses dynamic queries. I therefor can 
>>not determine what are the most common queries.
>>
>>I have used the postgresql logging ption before. Is there a tool to 
>>analyze the logfile for the most common and/or most time consuming queries?
> 
> 
> You can log queries that run for at least a specified amount of time.
> This will be useful in finding what the long running queries are.
> You can then use explain analyse to see why they are long running.
But is there a tool that could compile a summary out of the log? The log 
grows awefully big after a short time.
Thanks
/Ulrich
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikola Milutinovic | 2004-08-12 11:02:32 | PgSQL 8.0.0 beta1 compile problem + patch | 
| Previous Message | Andrew Sullivan | 2004-08-12 10:25:04 | Re: Replication options? | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Richard Huxton | 2004-08-12 11:16:20 | Re: [GENERAL] How to know which queries are to be optimised? | 
| Previous Message | Pierre-Frédéric Caillaud | 2004-08-12 06:49:37 | Re: Hardware upgrade for a high-traffic database |