From: Tomas Vondra <tv@fuzzy.cz>
To: pgsql-performance@postgresql.org
Subject: Re: Common slow query reasons - help with a special log
Date: Sun, 11 Dec 2011 00:50:56 +0100
Message-ID: <4EE3F060.6000602@fuzzy.cz> (raw)
In-Reply-To: <CACffM9HcN8JY+e7O_NXTT84Oi_YHubU1_d1obpTHzBUUPotL-Q@mail.gmail.com>
References: <CACffM9E1d9bR=xdWYoAPF2Y2NMpfE4gpRQf6vjV3QXQ5SSSLbw@mail.gmail.com>
<4EE39620.5020703@fuzzy.cz>
<CACffM9HcN8JY+e7O_NXTT84Oi_YHubU1_d1obpTHzBUUPotL-Q@mail.gmail.com>
On 10.12.2011 23:40, Daniel Cristian Cruz wrote:
> At work we have a 24 cores server, with a load average around 2.5.
A single query is processes by a single CPU, so even if the system is
not busy a single query may hit CPU bottleneck. The real issue is the
instrumentation overhead - timing etc. On some systems (with slow
gettimeofday) this may be a significant problem as the query hits the
CPU boundary sooner.
> I don't know yet if a system which use some unused CPU to minimize the
> load of a bad query identified early is bad or worse.
Not really, due to the "single query / single CPU" rule.
> Indeed, I don't know if my boss would let me test this at production
> too, but it could be good to know how things work in "auto-pilot" mode.
What I was pointing out is that you probably should not enable loggin
"explain analyze" output by "auto_explain.log_analyze = true". There are
three levels of detail:
1) basic, just log_min_duration_statement
2) auto_explain, without 'analyze' - just explain plain
3) auto_explain, with 'analyze' - explain plan with actual values
Levels (1) and (2) are quite safe (unless the minimum execution time is
too low).
Tomas
>
> 2011/12/10 Tomas Vondra <tv@fuzzy.cz <mailto:tv@fuzzy.cz>>
>
> There's auto_explain contrib module that does exactly what you're asking
> for. Anyway, explain analyze is quite expensive - think twice before
> enabling that on production server where you already have performance
> issues.
>
> Tomas
>
> On 10.12.2011 17:52, Daniel Cristian Cruz wrote:
> > Hi all,
> >
> > I'm trying to figure out some common slow queries running on the
> server,
> > by analyzing the slow queries log.
> >
> > I found debug_print_parse, debug_print_rewritten, debug_print_plan,
> > which are too much verbose and logs all queries.
> >
> > I was thinking in something like a simple explain analyze just for
> > queries logged with log_min_duration_statement with the query too.
> >
> > Is there a way to configure PostgreSQL to get this kind of
> information,
> > maybe I'm missing something? Is it too hard to hack into sources
> and do
> > it by hand? I never touched PostgreSQL sources.
> >
> > I'm thinking to write a paper that needs this information for my
> > postgraduate course. The focus of my work will be the log data, not
> > PostgreSQL itself. If I succeed, maybe it can be a tool to help
> all of us.
> >
> > Thank you,
> > --
> > Daniel Cristian Cruz
> > クルズ クリスチアン ダニエル
>
>
> --
> Sent via pgsql-performance mailing list
> (pgsql-performance@postgresql.org
> <mailto:pgsql-performance@postgresql.org>)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
>
>
>
> --
> Daniel Cristian Cruz
> クルズ クリスチアン ダニエル
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tv@fuzzy.cz
Subject: Re: Common slow query reasons - help with a special log
In-Reply-To: <4EE3F060.6000602@fuzzy.cz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox