From: | Guillermo Schulman <gschulman_ml(at)yahoo(dot)com(dot)ar> |
---|---|
To: | lista de correo de postgres <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Cache o similar |
Date: | 2005-02-28 19:58:27 |
Message-ID: | 422377E3.8050507@yahoo.com.ar |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Hola a todos.
Estoy trabajando con una consulta que en ciertas ocasiones tiene muy mala performance. Al correr la consulta por primera vez después de un tiempo sin haberlo corrido le toma como 20 segundos para resolverlo. Al volver a intentarlo inmediatamente, le toma menos de medio segundo con exactamente el mismo plan de ejecución.
La pregunta es: existe algún tipo de memoria/cache que guarda resultados "precompilados" o algo similar? Cómo puedo configurarlo para tener un mayor control sobre eso? Puede llegar a estar relacionado con algún otro tema? Agradeceré cualquier dato que pueda servirme como pista.
Utilizamos PG versión 7.2.1
Gracias.
Esta es la consulta en cuestión
SELECT tracker.trackerId,tracker.trackerType,tracker.invoiceId,invoice_tracker.rushid,ordertable.invoiceorigin
FROM invoice_tracker
INNER JOIN tracker ON tracker.invoiceId = invoice_tracker.invoiceId
INNER JOIN ordertable ON tracker.orderid = ordertable.orderid
WHERE
invoice_tracker.receivedDate ISNULL AND
tracker.state = 40 AND
(invoice_tracker.holdDate IS NOT NULL OR invoice_tracker.accountHoldDate ISNULL)
Este es el reultado del EXPLAIN ANALYZE para el primer intento:
Nested Loop (cost=0.00..4291.03 rows=1 width=609) (actual time=291.37..18567.03 rows=1736 loops=1)
-> Nested Loop (cost=0.00..4287.37 rows=1 width=599) (actual time=259.37..14790.06 rows=1736 loops=1)
-> Index Scan using tracker_state on tracker (cost=0.00..1067.66 rows=625 width=194) (actual time=97.22..7385.82 rows=1736 loops=1)
-> Index Scan using invoice_tracker_pkey on invoice_tracker (cost=0.00..5.14 rows=1 width=405) (actual time=3.29..4.22 rows=1 loops=1736)
-> Index Scan using ordkey on ordertable (cost=0.00..3.65 rows=1 width=10) (actual time=2.11..2.13 rows=1 loops=1736)
Total runtime: 18572.17 msec
Este es el reultado del EXPLAIN ANALYZE para todos los intentos posteriores (por un buen período de tiempo a partir de la última vez que se haya corrido la misma consulta):
Nested Loop (cost=0.00..4291.03 rows=1 width=609) (actual time=0.63..396.88 rows=1736 loops=1)
-> Nested Loop (cost=0.00..4287.37 rows=1 width=599) (actual time=0.47..249.12 rows=1736 loops=1)
-> Index Scan using tracker_state on tracker (cost=0.00..1067.66 rows=625 width=194) (actual time=0.31..98.15 rows=1736 loops=1)
-> Index Scan using invoice_tracker_pkey on invoice_tracker (cost=0.00..5.14 rows=1 width=405) (actual time=0.04..0.06 rows=1 loops=1736)
-> Index Scan using ordkey on ordertable (cost=0.00..3.65 rows=1 width=10) (actual time=0.05..0.05 rows=1 loops=1736)
Total runtime: 400.49 msec
En todos los casos existe una notable diferencia en el tiempo que efectivamente le lleva ejecutar cada nodo (actual time).
Qué es lo que puede estar ocasionándolo?
Gracias nuevamante.
From | Date | Subject | |
---|---|---|---|
Next Message | Leonel Quinteros | 2005-02-28 20:02:25 | Usuario para backup en Windows 2003 |
Previous Message | Claudia Villa | 2005-02-28 19:41:28 | como manejar selects recursivos? |