From: | "Guillermo E(dot) Villanueva" <guillermovil(at)gmail(dot)com> |
---|---|
To: | Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar> |
Cc: | pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org>, gilberto castillo <gilberto(dot)castillo(at)etecsa(dot)cu> |
Subject: | Re: Ayuda para optimizar consulta |
Date: | 2015-05-11 01:55:09 |
Message-ID: | CANm+PCA2NGXytywA3wkr_3VknjC_kdGWtHEpsXHPH6YgXLmxKA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Muchas gracias por tu aporte Gerardo, mi pregunta apuntaba mas a la
condición de reunión, cuando son varias columnas las que intervienen en la
reunión , se puede armar algún índice? Veo que el planificador hace un sort
previo.
Guillermo Villanueva
El 9 de mayo de 2015, 14:46, Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar> escribió:
>
>
> ----- Mensaje original -----
> > De: "Guillermo E. Villanueva" <guillermovil(at)gmail(dot)com>
> > Para: "gilberto castillo" <gilberto(dot)castillo(at)etecsa(dot)cu>
> > CC: "pgsql-es-ayuda" <pgsql-es-ayuda(at)postgresql(dot)org>
> > Enviados: Viernes, 8 de Mayo 2015 8:24:20
> > Asunto: Re: [pgsql-es-ayuda] Ayuda para optimizar consulta
> >
> >
> > Buenos días, les cuento que hice varias pruebas, entre ellas crear un
> > índice en ambas tablas del join con las columnas:
> >
> >
> >
> > uploaddet_importcomp
> >
> >
> >
> > * fil_ clasedoc
> > * fil_ tipodoc
> > * fil_ nrodoc
> > * fil_ nacim
> >
> >
> >
> >
> >
> >
> > historicotemp
> >
> >
> > * aficlasedoc
> > * historicotemp.afitipodoc
> > * historicotemp.afidni
> > * historicotemp.afifechanac
> >
> >
> >
> >
> >
> > También probé haciéndo un índice con las columnas concatenadas, de
> > todas maneras el planificador siempre decía que iba a hacer un seq
> > scan y un sort por esos campos. Solo fue un poco mas rápido cuando
> > cambié de left a inner así que tuve que cambiar la lógica de la
> > aplicación.
> > Una pregunta concreta, ¿hay algún índice que se pueda crear con estas
> > columnas para que el planificador lo aproveche y mejore la
> > performance?
> >
> >
> No necesariamente. Si el "where" de la consulta devuelve una parte
> significativa de la tabla, entonces seguramente el planificador decidira
> que es mas performante leer directamente (de manera secuencial) de la
> tabla, para luego aplicarle un filtro.
>
> Para corroborar las velocidades "secuencial vs index", intenta leer sobre
> estas variables:
> set enable_indexscan
> set enable_bitmapscan
> set enable_seqscan
>
> Para que puedas comprobar empiricamente las alternativas del planificador.
>
> Saludos,
> Gerardo
>
From | Date | Subject | |
---|---|---|---|
Next Message | Gilberto Castillo | 2015-05-11 12:51:49 | Re: Ayuda para optimizar consulta |
Previous Message | Gerardo Herzig | 2015-05-09 17:46:00 | Re: Ayuda para optimizar consulta |