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

Re: Bajo rendimiento en postgresql cuando se lanza un delete

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Francisco Manuel Quintana Trujillo <fquintana(at)itccanarias(dot)org>
Cc: Fernando Hevia <fhevia(at)ip-tel(dot)com(dot)ar>, pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Bajo rendimiento en postgresql cuando se lanza un delete
Date: 2009-08-01 00:23:23
Message-ID: 20090801002323.GE11098@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Francisco Manuel Quintana Trujillo escribió:
> 
> Hola,
> 
> La estructura de la base de datos pertenece a un proyecto GIS desarrollado por www.52North.org por lo tanto puedo realizar modificaciones hasta cierto punto.
> 
> Realicé los siguientes cambios:
> 
> En la tabla "observation" eliminé temporalmente las reglas que estaban creadas 
> -- Rule: "offering_delete_actualization ON observation"
> -- Rule: "offering_insert_actualization ON observation" No afecta al delete
> -- Rule: "offering_update_actualization ON observation" No afecta al delete
> 
> Además, modifiqué la consulta 
> delete from observation
> where observation_id in (select observation_id from observation EXCEPT select observation_id from quality);

Hmm, quizás así:

delete from observation
where not exists (select 1
                    from quality
                   where quality.observation_id = observation_id);

Esto produce un plan de la siguiente forma:

                                                        QUERY PLAN                                                        
--------------------------------------------------------------------------------------------------------------------------
 Result  (cost=3.39..1446.39 rows=100000 width=6) (actual time=0.092..774.735 rows=100000 loops=1)
   One-Time Filter: $0
   InitPlan 1 (returns $0)
     ->  Seq Scan on quality  (cost=0.00..339.00 rows=100 width=4) (actual time=0.051..0.051 rows=1 loops=1)
           Filter: (observation_id = observation_id)
   ->  Seq Scan on observation  (cost=0.00..1443.00 rows=100000 width=6) (actual time=0.029..316.555 rows=100000 loops=1)
 Total runtime: 2155.575 ms
(7 filas)


Creo que debería ser más rápido.  Sin embargo, en un caso de prueba la
consulta que tú tenías originalmente me da este plan:

                                      QUERY PLAN                                       
---------------------------------------------------------------------------------------
 Seq Scan on observation  (cost=720.25..760.25 rows=1200 width=6)
   Filter: (NOT (hashed SubPlan 1))
   SubPlan 1
     ->  Unique  (cost=0.00..670.25 rows=20000 width=4)
           ->  Index Scan using q_i on quality  (cost=0.00..620.25 rows=20000 width=4)
(5 filas)


Quizás la solución a tu problema es migrar a 8.4 ...

-- 
Alvaro Herrera                          Developer, http://www.PostgreSQL.org/
"Hoy es el primer día del resto de mi vida"

In response to

pgsql-es-ayuda by date

Next:From: Emanuel Calvo FrancoDate: 2009-08-01 00:49:19
Subject: Re: PgRouting
Previous:From: Emanuel Calvo FrancoDate: 2009-07-31 23:48:44
Subject: Re: Acerca de PGDay 2009 Buenos Aires participación?==?UTF-8?Q? comunidad cubana confirmación

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