Re: Optimización de consulta

Hola

El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva <
guillermovil(at)gmail(dot)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 (<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)
>>
>