Re: Indexes parciales

Gracias a todos por sus comentarios, creo que muchos aprendimos mucho mas
acerca de indexes y como funcionan.

En mi caso, solo me sorprendio con los recursos disponibles y porque en
production la ejecucion de esa consulra no toma ese tiempo, entonces
despues del comentario de muchos me percate que ese resultado se debe a que
en performance environment la data en esa tabla no tiene completo sentido,
entonces no podria esperar que los indexes en perfomance usaran el mismo
plan que en production si la data no es remotamente parecida.

Lo otro que vi es como postgre utiliza los indexes creado con multiples
columnas incluso no todas las columnas de ese indices aparescan en la
consulta, y eso es algo de lo cual no me habia percatado hasta que hice
esos test, pensaba que todas las columnas del index debian aparecer para
que el index fuera seleccionado.

Thanks,
Carlos

On Thu, Sep 5, 2019 at 10:57 AM Jose Mercedes Venegas Acevedo <
jvenegasperu(at)gmail(dot)com> wrote:

> Nahum gracias por la sugerencia pero he probado lo de las vistas y ahí sí
> que la cosa es súper lenta para que vaya rápido se requiere vistas
> materializada ahí si vuela el.problema es que la vista materializada no se
> actualiza inmediatamente sino cada cierta frecuencia con una tarea
> programada en el servidor al hacerlo directamente sobre la tabla los
> cambios se ven de forma instantánea la prox semana trabajaré en la
> migración haber cómo me va con la sugerencia de alvaro
>
> El jue., 5 de sep. de 2019 10:36 AM, Nahum Castro <nahumcastro(at)gmail(dot)com>
> escribió:
>
>> Una estrategia es que hagas indices espaciales, además de eso uses vistas
>> que te muestren solo lo que quieres ver, ie, pintas las manzanas y solo los
>> predios "rojos".
>>
>> Saludos.
>> Nahum
>>
>> El lun., 2 de sep. de 2019 a la(s) 17:23, Jose Mercedes Venegas Acevedo (
>> jvenegasperu(at)gmail(dot)com) escribió:
>>
>>> Hola Alvaro
>>> Buen dia
>>>
>>> conviene un seqscan. Leer el 99,98% de los registros de la tabla usando
>>>> un índice es absurdo, a falta de otras condiciones (ej si hubiera un
>>>> ORDER BY con el mismo orden del índice). Seguramente es posible
>>>> obligarlo a que haga lo que tú quieres, y seguramente será más lento que
>>>> lo actual.
>>>>
>>>> En este punto lo que tienes que preguntarte es qué diablos pretendes que
>>>> haga la aplicación con esos 306409 registros.
>>>>
>>>
>>> En particular no conozco el caso de uso de Carlos pero por ejemplo yo
>>> tengo una situacion similar en la que si debo tener miles de registros
>>> mostrandose con categorias entre 2 fechas y el escaneo siempre es
>>> secuencial porque en efecto siempre me tiene que devolver entre un 15% y un
>>> 35% de la tabla todo esto desde QGIS donde hay momentos en los que si se
>>> extraña que se pueda hacer mas rapido quiza activando algun parametro de
>>> postgres para que el planificador use mas de un procesdor en paralelo algo
>>> asi para aumentar la velocidad de respuesta.
>>>
>>> Esto lo muestro en la imagen 1 es el caso de Uso que tengo en particular
>>>
>>> Tambien hay otros casos en los que por un filtro si se tiene que mostrar
>>> de un color unos pocos y la gran mayoria de otro esto se ve en la imagen 2
>>>
>>> Adjunto las imagenes y si alguien conoce por ejemplo como decirle a
>>> postgres que use un indice cuando el resultado es por ejemplo el 20% de la
>>> tabla quizas eso ayude o quizas postgres calcula que devolver el 20% de la
>>> tabla con indice es mas costoso que hacerlo secuencial y por eso siempre lo
>>> hace asi. si alguien puede dar mas luces al respecto seria fabuloso, porque
>>> ya con 300 mil predios en la ciudad de vez en cuando la respuesta va lenta
>>> actualmente sucede un par de veces por semana. que al momento de renderizar
>>> en qgis la respuesta es lenta y ya descarte que se trate de qgis porque
>>> cuando hago lo mismo con un archivo Shape la cosa va muy rapido en cambio
>>> con postgis por instantes se nota la demora.
>>>
>>> Respondiendo a tu pregunta Alvaro lo que pretendo en mi caso que haga la
>>> aplicacion es que me muestre en Verde las Casas que estan ok y en rojo las
>>> pendientes de trabajo como se muestra en la imagen es un trabajo progresivo
>>> todos los meses se entiende que al final deben quedar todas en verde es lo
>>> ideal aunque siempre hay alguna pega los usos son diversos uno de ellos es
>>> por ejemplo controlar la toma de lectura de los medidores de agua, por
>>> ejemplo una casa se quedo en rojo porque cuando fueron a tomar la lectura
>>> habia un vehiculo estacionado sobre la caja de registro.
>>>
>>> lamento no poder aportar alguna solucion pero quizas quienes lean esto
>>> puedan aportar algun alcance sobre las consultas que tambien estoy haciendo
>>> aqui pienso que esto esta relacionado con la pregunta inicial de Carlos
>>> solo que yo lo estoy mostrando graficamente porque las consultas son tal
>>> cual como el las expuso al inicio.
>>>
>>> Saludos a todos
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>> --
>>>> Álvaro Herrera https://www.2ndQuadrant.com/
>>>> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>>>>
>>>>
>>>>
>>>
>>> --
>>> José Mercedes Venegas Acevedo
>>> cel Mov RPC 964185205
>>>
>>>
>>>
>>
>> --
>> *Nahum Castro González*
>> Blvd. Perdigón 214, Brisas del Lago.
>> CP 37207
>> León, Guanajuato, México
>> Tel (477)1950304
>> Cel (477)1274694
>>
>