Re: measuring most-expensive queries

From: Gourish Singbal <gourish(at)gmail(dot)com>
To: weigelt(at)metux(dot)de, pgsql-admin <pgsql-admin(at)postgresql(dot)org>
Subject: Re: measuring most-expensive queries
Date: 2005-05-02 05:11:52
Message-ID: 674d1f8a0505012211d858cb6@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

You could have made the following change in your conf file and reload
the postgresql server.

log_min_duration_statement = 10000

This will help you log the queries that take more than 10000 mili
seconds to execute in your postgresql sever log file

regards
Gourish Singbal

On 5/2/05, Enrico Weigelt <weigelt(at)metux(dot)de> wrote:
>
> Hi folks,
>
> I'd like to find out which queries are most expensive (taking very
> long or producing high load) in a running system, to see what
> requires further optimization. (the application is quite large
> and some more folks involved, so I cant check evrything manually).
>
> Well, the postmaster can log ev'ry single statement, but its
> really too for a human person, to read the log files.
>
> Is there any tool for that ?
>
> thx
> --
> ---------------------------------------------------------------------
> Enrico Weigelt == metux IT service
> phone: +49 36207 519931 www: http://www.metux.de/
> fax: +49 36207 519932 email: contact(at)metux(dot)de
> ---------------------------------------------------------------------
> Realtime Forex/Stock Exchange trading powered by postgresSQL :))
> http://www.fxignal.net/
> ---------------------------------------------------------------------
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Best,
Gourish Singbal

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Mauri Sahlberg 2005-05-02 06:19:28 A nightmare
Previous Message Ezequiel Tolnay 2005-05-02 04:52:49 Re: pg_version_history