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
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"

In response to

Browse pgsql-es-ayuda by date

  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