Re: Costo de una consulta mejorada

david buenaño wrote:
> Adjunto dos archivos de texto con los resultados de explain analyze. muchas
> gracias

ok, guau! No esperaba un explain tan complejo (recibí a mi correo
personal un explain de 44 kB y otro de 29kB). Por favor mantén a la
lista de CC cuando respondas. Tu diseño debe involucrar un buen montón
de vistas, y unos cuantos UNION ALL etc. Estudiar esto en detalle no
voy a hacerlo en mi tiempo libre, pero el primer brazo interesante en la
consulta rápida es

-> Subquery Scan on ""*SELECT* 2"" (cost=46372.91..95452.26 rows=1 width=0) (actual time=348.445..348.446 rows=1 loops=1)
-> GroupAggregate (cost=46372.91..95452.25 rows=1 width=0) (actual time=348.443..348.443 rows=1 loops=1)
InitPlan 60 (returns $59)
-> Seq Scan on bjg_periodopago (cost=0.00..1.30 rows=1 width=4) (actual time=0.024..0.025 rows=1 loops=1)
Filter: (pep_estado = '1'::bpchar)
Rows Removed by Filter: 24"
-> Seq Scan on bjg_pago (cost=46371.61..95408.75 rows=8439 width=0) (actual time=158.295..348.337 rows=218 loops=1)
Filter: ((NOT (hashed SubPlan 62)) AND ((pag_estado)::text = 'ACT'::text) AND (pep_id = $59) AND ((pag_tipobeneficiario)::text = 'DISCAPACIDAD'::text))
Rows Removed by Filter: 359248
SubPlan 62
-> Index Only Scan using indx_cedula_periodo on bjg_pago (cost=1.30..46302.36 rows=27697 width=11) (actual time=0.059..66.522 rows=28719 loops=1)
Index Cond: (pep_id = $60)
Heap Fetches: 28719
InitPlan 61 (returns $60)
-> Seq Scan on bjg_periodopago (cost=0.00..1.30 rows=1 width=4) (actual time=0.018..0.019 rows=1 loops=1)
Filter: (pep_estado = '1'::bpchar)
Rows Removed by Filter: 24

mientras que en la consulta lenta el correspondiente es

-> Subquery Scan on ""*SELECT* 2"" (cost=0.00..680591431.41 rows=1 width=0) (actual time=99194.970..99194.970 rows=1 loops=1)
-> GroupAggregate (cost=0.00..680591431.40 rows=1 width=0) (actual time=99194.970..99194.970 rows=1 loops=1)
-> Index Scan using indx_cedula_periodo on bjg_pago (cost=0.00..680591386.97 rows=8883 width=0) (actual time=308.908..99194.760 rows=218 loops=1)
Index Cond: (pep_id = 25)
Filter: (((pag_estado)::text = 'ACT'::text) AND ((pag_tipobeneficiario)::text = 'DISCAPACIDAD'::text) AND (NOT (SubPlan 24)))
Rows Removed by Filter: 28773
SubPlan 24
-> Materialize (cost=0.00..46611.42 rows=29141 width=11) (actual time=0.004..2.922 rows=11509 loops=17699)
-> Seq Scan on bjg_pago (cost=0.00..46336.71 rows=29141 width=11) (actual time=27.617..253.504 rows=28719 loops=1)
Filter: (pep_id = 24)
Rows Removed by Filter: 330747"

Es claro que hacer un seqscan de esta table bjg_pago es mucho más rápido
de lo que el sistema parece creer. ¿tendrás la configuración del
optimizador modificada? cpu_tuple_cost, cpu_index_tuple_cost, cosas
así?

La otra posibilidad que se me ocurre es que el índice tenga mucho
"bloat"; en ese caso habría que considerar un reindex.

--
Álvaro Herrera http://www.twitter.com/alvherre

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda