Cache o similar

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.

Responses

Browse pgsql-es-ayuda by date

  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?