Re: Tratando de entender un plan de consulta con un INNER JOIN.

2012/8/8 Igor <igor(at)negora(dot)com>:
>
> Analizando el plan de la consulta (anteponiendo "analyze" a ésta) aparece
> esto:
>
> Hash Join (cost=15.34..31.26 rows=166 width=8)
> Hash Cond: (s.father_id = f.father_id)
> -> Seq Scan on sons s (cost=0.00..13.10 rows=310 width=8)
> -> Hash (cost=14.00..14.00 rows=107 width=4)
> -> Seq Scan on fathers f (cost=0.00..14.00 rows=107 width=4)
> Filter: (father_id < 10)
>
> Supongo que se me está escapando algo importante pero, ¿Por que en esa línea
> marcada en negrita (la búsqueda secuencial en "sons") el planificador no
> restringe la búsqueda también a aquellos hijos con código de padre menor a
> 10, como hace al buscar los padres? ¿Significa este plan que pese a obtener
> 10 padres, luego recorre absolutamente todos los hijos y no sólo los que
> tienen código de padre menor que 10 (pese a que hay un índice "btree" creado
> en la columna "father_id" de la tabla "sons")?
>
> He probado a llenar las tablas con 10 millones de registros y, tras ejecutar
> "analyze", el resultado es el mismo.
>

Que version de postgres esta? con solo 310 registros creo que es
normal que haga un seq scan pero con 10 millones deberia usar un
indice.

a mi me funciona asi (de hecho solo inserte 10000 en fathers y 30000
en sons) aun asi usa indices en ambas tablas (no necesita el filtro en
sons porque al usar el indice y chequear solo los resultados que
obtuvo de fathers el filtro esta implicito)

pero si, cuando hace un seq scan no hereda filtros aun cuando haya un
FK que relacione los dos campos.
ai quieres ver el filtro agregua una condicion "s.fathers_id < 10"
adicional si quieres que use ese filtro

pero, un seq scan igual leera toda la tabla (filtro o no filtro)

--
Jaime Casanova www.2ndQuadrant.com
Professional PostgreSQL: Soporte 24x7 y capacitación