Received: from localhost (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id C321764FEE7 for ; Wed, 17 Dec 2008 14:19:40 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 26139-09 for ; Wed, 17 Dec 2008 14:19:38 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.30]) by mail.postgresql.org (Postfix) with ESMTP id C555F64FD3B for ; Wed, 17 Dec 2008 14:19:37 -0400 (AST) Received: by yw-out-2324.google.com with SMTP id 3so9889ywj.73 for ; Wed, 17 Dec 2008 10:19:37 -0800 (PST) Received: by 10.151.108.13 with SMTP id k13mr1816917ybm.86.1229537976995; Wed, 17 Dec 2008 10:19:36 -0800 (PST) Received: by 10.151.153.17 with HTTP; Wed, 17 Dec 2008 10:19:36 -0800 (PST) Message-ID: <3073cc9b0812171019n2244ecfaibf4c514986a69dee@mail.gmail.com> Date: Wed, 17 Dec 2008 13:19:36 -0500 From: "Jaime Casanova" To: "Robert Haas" Subject: Re: measure database contention Cc: "psql performance list" In-Reply-To: <603c8f070812170856g7ae06d58q2f487bead5f7be15@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <3073cc9b0812161132w3ae157a8n69e2b0cccea05ca2@mail.gmail.com> <603c8f070812170618g3116a90du94cbf102f0336d59@mail.gmail.com> <3073cc9b0812170738v69e43d89r8d6dae87453b4993@mail.gmail.com> <603c8f070812170856g7ae06d58q2f487bead5f7be15@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200812/165 X-Sequence-Number: 32201 On Wed, Dec 17, 2008 at 11:56 AM, Robert Haas wrote= : >> is the exact query... i think it will be removed later today because >> is a bad query anyway... but my fear is that something like happens >> even with good ones... >> >> maybe chekpoints could be the problem? >> i have 8.3.5 and condigured checkpoint_timeout in 15 minutes, >> chekpoint_segments 6 and checkpoint_completion_target to 0.5 > > Well, it might help if you could provide the query, and the EXPLAIN outpu= t. > ok... remember i say it's a bad query ;) actually, seems there's a suitable index for that query (i guess it is using it because of the order by) mic=3D# explain analyze mic-# SELECT * FROM tgen_persona ORDER BY empresa_id, persona_id ASC; QUERY PLAN ---------------------------------------------------------------------------= ------------------------------------------------------------------ Index Scan using pk_tgen_persona on tgen_persona (cost=3D0.00..8534.09 rows=3D86547 width=3D884) (actual time=3D0.096..129.980 rows=3D86596 loops= =3D1) Total runtime: 175.952 ms (2 rows) as you see, explain analyze says it will execute in 175.952ms and because of network transfer of data executing this from pgadmin in another machine it runs for 17s... but from time to time pgFouine is shown upto 345.11 sec --=20 Atentamente, Jaime Casanova Soporte y capacitaci=F3n de PostgreSQL Asesor=EDa y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157