Re: Optimización de consulta

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 (<alvherre(at)alvh(dot)no-ip(dot)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)
>