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 < guillermo...@gmail.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 < > rauland...@gmail.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 < >> 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 >> > -- Raul Andres Gutierrez Alejo