Ok, muchas gracias Daymel

El mar, 7 jun 2022 a las 14:58, Daymel Bonne Solís (<daymelbo...@gmail.com>)
escribió:

>
>
> El mar, 7 jun 2022 a la(s) 12:21, Guillermo E. Villanueva (
> guillermo...@gmail.com) escribió:
>
>> Buenas tardes cómo andan? quizá me puedan dar una mano, estoy tratando de
>> optimizar una consulta con varios joins, agrupamientos y unos cuantos
>> filtros, según lo que puedo ver en el explain  las expresiones:
>>
>> *product_.status = 1 and and product_.qty > 0*
>>
>> provocan seq. scan y el mayor costo y tiempo de mi consulta
>> la tabla product_ tiene 69300 filas
>> status = 1 son 49500
>> qty > 0 son 65700
>>
>> el explain me dice:
>> ->  Parallel Seq Scan on product_  (cost=0.00..19483.64 rows=19580
>> width=30) (actual time=0.032..39.454 rows=15674 loops=3)
>>     Filter: ((qty > '0'::numeric) AND (status = 1))
>>      Rows Removed by Filter: 7454
>>
>> Si creo índices individuales o combinando ambas columnas no mejora, sigue
>> haciendo seq. scan
>>
>> Creen que hay alguna forma de mejorarlo? o ya estoy en la mejor versión
>> de la query?
>>
>> Desde ya muchas gracias por las ideas.
>>
>
> La explicación del comportamiento viene dado por los datos que nos
> muestras:
>
> Total de registros: 69300
> Tuplas que cumplen con `status = 1` son 49500 representa el 71%
> Tuplas que cumplen con `qty > 0` son 49500 que son 84%
>
> Postgres no utilizará índices, es ménos costoso hacer un scan secuencial
> sobre la tabla que primero buscar en los índices y luego ir a la tabla para
> obtener los registros.
>
> Saludos
>
>

Reply via email to