From: | "Guillermo E(dot) Villanueva" <guillermovil(at)gmail(dot)com> |
---|---|
To: | Anthony Sotolongo <asotolongo(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-es-ayuda <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Optimización de consulta |
Date: | 2022-06-07 18:41:22 |
Message-ID: | CANm+PCCVibG6Y3OyzCZOvNj==nJ7PNmk8iATg4dq4OP+JbZGoQ@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Entendido, gracias
El mar, 7 jun 2022 a las 15:18, Anthony Sotolongo (<asotolongo(at)gmail(dot)com>)
escribió:
> 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)
>>>
>>
From | Date | Subject | |
---|---|---|---|
Next Message | Horacio Miranda | 2022-06-07 20:36:30 | Re: Optimización de consulta |
Previous Message | Guillermo E. Villanueva | 2022-06-07 18:41:01 | Re: Optimización de consulta |