Re: Optimización de consulta

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)
>>>
>>

In response to

Responses

Browse pgsql-es-ayuda by date

  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