Hola Guillermo. el planificador de postgres realizar un Seq Scan si el 80% de los datos de una tabla va a ser leídos y para este caso son 1096 rows de 1200(91%), se puede desactivar el seq scan para una consulta especifica con set enable_seqscan = off , o en el config para todo el motor lo cual no es muy recomendable, yo recomiendo que ejecute un explain analyze y compara los rows estimado y rows obtenido si hay mucha diferencia se debe aumentar el tamaño de las estadísticas con ALTER TABLE nomenclador ALTER COLUMN nom_id SET STATISTICS 500; y realizar un vacuum analyze en la tabla nomenclador, si los registros del select si son 1096 es mas eficiente un seq scan que solo lee el 91% de los datos, que un index scan que primero un indice y luego el 91% de los datos.
El 18 de diciembre de 2014, 8:30, Guillermo E. Villanueva < guillermo...@gmail.com> escribió: > > Buenos días, los molesto para consultarles sobre un explain que me llama > la atención. > La consulta que analizo es: > explain SELECT > c.id_comprobante, > c.fecha_comprobante, > s.afiapellido, > s.afinombre, > s.afidni, > s.clavebeneficiario, > string_agg(tp_codigo||nom_objetopres||coalesce(p.diag_codigo,v.diag_codigo), > ' - ') prestaciones, > sum(cantidad*precio_prestacion) subtt > FROM > facturacion.comprobante c > inner join facturacion.prestacion2 p using(id_comprobante) > inner join facturacion.valuacion v using (id_valuacion) > inner join facturacion.nomenclador2 using(nom_id) > left join nacer.smiafiliados s using(id_smiafiliados) > WHERE > id_factura=5675 > GROUP BY > 1,2,3,4,5,6 > ORDER BY > c.id_comprobante DESC > > El resultado que obtengo es: > "GroupAggregate (cost=23601.13..23610.25 rows=192 width=84)" > " -> Sort (cost=23601.13..23601.61 rows=192 width=84)" > " Sort Key: c.id_comprobante, c.fecha_comprobante, s.afiapellido, > s.afinombre, s.afidni, s.clavebeneficiario" > " -> Nested Loop Left Join (cost=467.36..23593.85 rows=192 > width=84)" > " -> Hash Join (cost=467.36..22059.15 rows=192 width=42)" > " Hash Cond: (v.nom_id = nomenclador2.nom_id)" > " -> Nested Loop (cost=423.70..22012.85 rows=192 > width=38)" > " -> Hash Join (cost=423.70..21062.50 rows=192 > width=35)" > " Hash Cond: (p.id_comprobante = > c.id_comprobante)" > " -> Seq Scan on prestacion2 p > (cost=0.00..16818.19 rows=1018319 width=23)" > " -> Hash (cost=420.87..420.87 rows=226 > width=16)" > " -> Index Scan using > "IX_Relationship4" on comprobante c (cost=0.00..420.87 rows=226 width=16)" > " Index Cond: (id_factura = > 5675)" > " -> Index Scan using valuacion_pk on valuacion > v (cost=0.00..4.94 rows=1 width=11)" > " Index Cond: (v.id_valuacion = > p.id_valuacion)" > " -> Hash (cost=29.96..29.96 rows=1096 width=12)" > " -> *Seq Scan on nomenclador2 > (cost=0.00..29.96 rows=1096 width=12)"* > " -> Index Scan using smiafiliados_pkey on smiafiliados s > (cost=0.00..7.98 rows=1 width=50)" > " Index Cond: (c.id_smiafiliados = s.id_smiafiliados)" > > Y lo que me llama la atención, es la línea marcada con rojo, ya que dice > que va a utilizar una búsqueda secuencial. > Supongo que establecida una fila de la tabla valuación, proyecta el valor > de la columna nom_id para obtener la correspondiente fila relacionada de > nomenclador2, y esta tabla, de unas 1200 filas, tiene como clave primaria > justamente a nom_id. Entonces, porque el planificador dice que va a > utilizar una búsqueda secuencial? No sería lo lógico que utilice un acceso > por índice? > > Desde ya muchas gracias por las aclaraciones que me puedan brindar y por > tomarse el tiempo de leer todo esto. > > Saludos. > > Guillermo Villanueva > > -- Raul Andres Gutierrez Alejo
