Raul hice todo lo que me aconsejaste y no mejoro la velocidad creo que el problema esta en el ordenamiento.
si ejecuto sin order by b.id desc, la consulta es rapida la respuesta es milisegundos. si solo ejecuto order by b.id tambien mejora un poco la velocidad en la consulta. si ejecuto order by b.id desc tarda 8 segundos. El 3 de febrero de 2014, 12:51, raul andrez gutierrez alejo < rauland...@gmail.com> escribió: > basado en http://explain.depesz.com/s/xum. > > recomiendo cree los indices necesarios sobre las tablas documento_bien y > documento, aumente la estadisticas de los campos > b.idmunicipio,documento_bien.idbien y b.id, con 'ALTER TABLE "tabla" > ALTER COLUMN "campo" SET STATISTICS 500;' cree un indes desc en el campos > b.id para que el order by sea mas rápido y por ultimo realice un vacuum > analyze a toda la DB. > > > > > El 3 de febrero de 2014, 11:02, Linder Poclaba Lazaro <linder...@gmail.com > > escribió: > > la consulta es la siguiente: >> >> select b.id as idbien,b.codigo_activo as >> codigoactivo,replace(coalesce(b.direccion,'')||' >> '||coalesce(b.numero,'')||' '||coalesce(b.zona,''), '\n',' ') as direccion, >> m.departamento as nombre_departamento, >> replace(i.denominacion, '\t',' ') as >> denominacion,tb.descripcion as descripcion,i.superficie_terreno as >> superficie,eb.descripcion as estado,u.descripcion as uso, >> case when cd.nombres is null then 'SIN DOCUMENTACION' >> else cd.nombres end as documentos >> from dj_activos.bien b >> join dj_activos.inmueble i on b.id=i.idbien >> join geografia.vista_municipios m on >> m.idmunicipio=b.idmunicipio >> join dj_activos.tipobien tb on tb.id=b.idtipobien >> join dj_activos.estadobien eb on eb.id=b.idestadobien >> join dj_activos.uso u on u.id=b.iduso >> LEFT JOIN dj_documento.cadena_documentos cd on >> cd.idbien = b.id >> where identidad=78 and i.idbien not in (select idbien >> FROM dj_activos.bajasbienes) >> order by b.id desc >> limit 10 offset 0 >> >> >> >> >> El 3 de febrero de 2014, 11:38, Fede Martinez < >> federicoemarti...@gmail.com> escribió: >> >> cual es la consulta? que pinta tienen las tablas? >>> >>> >>> El 3 de febrero de 2014, 11:45, Linder Poclaba Lazaro < >>> linder...@gmail.com> escribió: >>> >>> la ejecución del explain devolvió lo siguiente >>>> >>>> http://explain.depesz.com/s/xum >>>> >>>> >>>> >>>> >>>> El 3 de febrero de 2014, 10:00, raul andrez gutierrez alejo < >>>> rauland...@gmail.com> escribió: >>>> >>>>> es necesario tener mas datos, recomiendo ejecute un explain analyse, >>>>> en pgadmin shift+F7 y el resultado lo copie en >>>>> http://explain.depesz.com/ , envia los 2 link y así podemos >>>>> asesorarte mejor. >>>>> >>>>> >>>>> El 3 de febrero de 2014, 8:53, Linder Poclaba Lazaro < >>>>> linder...@gmail.com> escribió: >>>>> >>>>> Buenos días a todos de la lista, me gustaria que iluminaran mis dudas, >>>>>> tengo una consulta que me devuelve datos en un tiempo aceptable menos de >>>>>> 1 >>>>>> segundo, pero al colocar en la consulta limit y offset la consulta >>>>>> consulta >>>>>> tarda entre 7 y 8 segundos, me gustaria saber el porque pasa eso, que >>>>>> estoy >>>>>> haciendo mal, que consejos me pueden dar. >>>>>> >>>>>> Gracias de antemano a todos los que respondan. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Raul Andres Gutierrez Alejo >>>>> >>>> >>>> >>> >> > > > -- > Raul Andres Gutierrez Alejo >
