Martín, tal como lo decís, sin límit el planificador resuelve el join con seq scan y al poner limit ya utiliza los índices. Te pido si vos tenés en claro porque no usa el índice para joins de tablas tan grandes que me lo expliques porque lo que me comentás no creo que justifique el descarte del índice, yo entiendo que por cada fila de h debe buscar la coincidencia de la fila de s (s.clavebeneficiario es PK en s!) al ser tan grande s y al tener que buscar una sola fila, ¿No es mas rápido con el índice?
Desde ya muchas gracias Guillermo Villanueva El 26 de mayo de 2014, 14:24, Martín Marqués <[email protected]>escribió: > 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 >
