Re: Seq Scan

Hola.

el planificado dice *"rows=1096" *y usted " y esta tabla, de unas 1200
filas" eso me da el 91%.

El 18 de diciembre de 2014, 9:18, Guillermo E. Villanueva <
guillermovil(at)gmail(dot)com> escribió:
>
> Raúl muchas gracias por tu respuesta.
> Entiendo que si tendría que que obtener gran parte de la tabla
> nomenclador2 le conviene un Seq pero en este caso por cada fila de
> valuación, le corresponde un único valor de nomenclador2.
> Será que hace un seq para mandarlo todo a memoria?
>
>
> Guillermo Villanueva
>
>
> El 18 de diciembre de 2014, 10:52, raul andrez gutierrez alejo <
> raulandrez(at)gmail(dot)com> escribió:
>
>> 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
>>
>

--
Raul Andres Gutierrez Alejo