Muchas gracias por tu respuesta Alvaro, tal como suponias, despues de hacer: create index idx1 on product_(status); create index idx2 on product_(qty); set enable_seqscan to 0;
No mejoró la performance. Demora lo mismo o un poquito mas. De nuevo muchas gracias. Guillermo offtopic: Aprovecho para preguntar, ese "set" va a durar lo que dura la sesión? o es un set para todo el servidor y queda hasta un reinicio? El mar, 7 jun 2022 a las 14:59, Alvaro Herrera (<alvhe...@alvh.no-ip.org>) escribió: > Guillermo E. Villanueva escribió: > > > *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 > > La tabla es muy pequeña y las cláusulas son poco selectivas, así que el > seqscan ya es la mejor estrategia. Pero prueba haciendo "set > enable_seqscan to 0" a ver si usando un índice anda más rápido (dudoso). > Si la tabla fuera muy grande y la fracción de registros que tienen > status=1 AND qty>0 es suficientemente pequeña, podría resultar en un > plan distinto/mejor. > > -- > Álvaro Herrera PostgreSQL Developer — > https://www.EnterpriseDB.com/ > "Oh, great altar of passive entertainment, bestow upon me thy discordant > images > at such speed as to render linear thought impossible" (Calvin a la TV) >
