Re: Optimizar query

Martin Marques escribió:
>
> On Mon, 24 Jul 2006 13:39:56 -0300 (ART), Miguel Juliÿffffe1n de la Fuente <jmdelafuente(at)yahoo(dot)com(dot)ar> wrote:
> > Muestro el EXPLAIN ANALYZE, desde ya muchas gracias.
> >
> > EXPLAIN ANALYZE
> > SELECT the_geom, nombre FROM
> > shortest_path('SELECT id, source, target, cost FROM calles_tmp_edges where
> > partido=45', 6001, 9960, false, false) a
> > inner join calles_tmp b
> > inner join calles_nombre n
> > on b.idcalle=n.idcalle
> > on a.edge_id=b.edge_id
> > where partido=45
> >
> > "Merge Join (cost=2061.75..2721.72 rows=43665 width=77) (actual
> > time=1950.551..1991.743 rows=49 loops=1)"
> > " Merge Cond: ("outer".edge_id = "inner".edge_id)"
> > " -> Sort (cost=62.33..64.83 rows=1000 width=4) (actual
> > time=473.271..473.360 rows=50 loops=1)"
> > " Sort Key: a.edge_id"
> > " -> Function Scan on shortest_path a (cost=0.00..12.50 rows=1000
> > width=4) (actual time=472.492..472.652 rows=50 loops=1)"

Pero si te fijas el peor problema esta aqui: el estimador cree que va a
encontrar mil tuplas y encuentra cincuenta. Esto puede ser un factor
que destruya la capacidad de optimizar mucho mas este join; lo cual es
bastante malo porque en este plan se encuentra bastante afuera del arbol
de ejecucion.

Lo que yo intentaria es lo que ya dije: tomar el resultado de
shortest_path y meterlo en una tabla temporal, y convertir el resto de
la consulta para que use esa tabla. Es posible que sea mejor usar un
nested loop en vez de un merge join aca (o quizas no).

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.