Skip site navigation (1) Skip section navigation (2)

Re: measure database contention

From: "Jaime Casanova" <jcasanov(at)systemguards(dot)com(dot)ec>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "psql performance list" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: measure database contention
Date: 2008-12-17 18:19:36
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Wed, Dec 17, 2008 at 11:56 AM, Robert Haas <robertmhaas(at)gmail(dot)com> 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 output.

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=# 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=0.00..8534.09
rows=86547 width=884) (actual time=0.096..129.980 rows=86596 loops=1)
 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

Jaime Casanova
Soporte y capacitación de PostgreSQL
Asesoría y desarrollo de sistemas
Guayaquil - Ecuador
Cel. +59387171157

In response to


pgsql-performance by date

Next:From: Scott MarloweDate: 2008-12-17 18:57:33
Subject: Re: measure database contention
Previous:From: Robert HaasDate: 2008-12-17 16:56:56
Subject: Re: measure database contention

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group