Message-ID: <4EE3F060.6000602@fuzzy.cz>
Date: Sun, 11 Dec 2011 00:50:56 +0100
From: Tomas Vondra <tv@fuzzy.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: Common slow query reasons - help with a special log
References: 
 <CACffM9E1d9bR=xdWYoAPF2Y2NMpfE4gpRQf6vjV3QXQ5SSSLbw@mail.gmail.com>
	<4EE39620.5020703@fuzzy.cz>
	<CACffM9HcN8JY+e7O_NXTT84Oi_YHubU1_d1obpTHzBUUPotL-Q@mail.gmail.com>
In-Reply-To: 
 <CACffM9HcN8JY+e7O_NXTT84Oi_YHubU1_d1obpTHzBUUPotL-Q@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 =3D true". There ar=
e
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

>=20
> 2011/12/10 Tomas Vondra <tv@fuzzy.cz <mailto:tv@fuzzy.cz>>
>=20
>     There's auto_explain contrib module that does exactly what you're a=
sking
>     for. Anyway, explain analyze is quite expensive - think twice befor=
e
>     enabling that on production server where you already have performan=
ce
>     issues.
>=20
>     Tomas
>=20
>     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_pla=
n,
>     > which are too much verbose and logs all queries.
>     >
>     > I was thinking in something like a simple explain analyze just fo=
r
>     > 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, n=
ot
>     > PostgreSQL itself. If I succeed, maybe it can be a tool to help
>     all of us.
>     >
>     > Thank you,
>     > --
>     > Daniel Cristian Cruz
>     > =E3=82=AF=E3=83=AB=E3=82=BA =E3=82=AF=E3=83=AA=E3=82=B9=E3=83=81=E3=
=82=A2=E3=83=B3 =E3=83=80=E3=83=8B=E3=82=A8=E3=83=AB
>=20
>=20
>     --
>     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
>=20
>=20
>=20
>=20
> --=20
> Daniel Cristian Cruz
> =E3=82=AF=E3=83=AB=E3=82=BA =E3=82=AF=E3=83=AA=E3=82=B9=E3=83=81=E3=82=A2=
=E3=83=B3 =E3=83=80=E3=83=8B=E3=82=A8=E3=83=AB