El día 26 de mayo de 2014, 10:23, Guillermo E. Villanueva <[email protected]> escribió: > explain > select * > from > nacer.historicotemp h > inner join nacer.smiafiliados s on > h.clavebeneficiario = s.clavebeneficiario; > > Con siguiente resultado > > "Hash Join (cost=33335.39..1817942.71 rows=5692774 width=1002)" > " Hash Cond: ((h.clavebeneficiario)::text = (s.clavebeneficiario)::text)" > " -> Seq Scan on historicotemp h (cost=0.00..578624.74 rows=5692774 > width=762)" > " -> Hash (cost=15677.73..15677.73 rows=394773 width=240)" > " -> Seq Scan on smiafiliados s (cost=0.00..15677.73 rows=394773 > width=240)" > > Ambas tablas tienen indexada la columna clavebeneficiario y como ven ambas > tablas creo que son lo suficientemente grande para la prueba. > (La tabla h tiene mas de 5 millones de registros y la tabla s tiene unos 400 > mil registros) > Yo esperaba que al join lo haga utilizando índices, sin embargo veo que el > planificador no lo usa, ¿Tienen idea por qué?
Eso es porque de todas formas va a tener que leer las dos tablas completas para poder entregarte las tuplas que se generan con el JOIN. Postgres sabe eso, y por lo tanto hace la busqueda secuencial (sino tendria que usar el indice y después hacer una busqueda secuencial, lo que es más costoso). Agregale un LIMIT 100 al final y veras que usa los indices. P.D.: Una consulta que retorna 5692774 filas no parece muy interesante. Saludos, -- Martín Marqués http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services - Enviado a la lista de correo pgsql-es-ayuda ([email protected]) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
