Hola El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva < guillermo...@gmail.com> escribió:
> 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 set ese va a durar lo que dure su sesión Saludos > > > > 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) >> >
