----- Mensaje original ----- > De: "Guillermo E. Villanueva" <guillermo...@gmail.com> > Para: "gilberto castillo" <gilberto.casti...@etecsa.cu> > CC: "pgsql-es-ayuda" <pgsql-es-ayuda@postgresql.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 - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
