Re: Seq Scan

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 <
guillermovil(at)gmail(dot)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