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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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"
From | Date | Subject | |
---|---|---|---|
Next Message | Emanuel Calvo Franco | 2009-08-01 00:49:19 | Re: PgRouting |
Previous Message | Emanuel Calvo Franco | 2009-07-31 23:48:44 | Re: Acerca de PGDay 2009 Buenos Aires participación comunidad cubana confirmación |