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 > >
