Re: Optimización de consulta

Solo para complementar.

On 8/06/2022 6:41 am, Guillermo E. Villanueva wrote:
> 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.
>
Para ver lo que hace el postgresql  ( si usa el cache buffers ) trata de
hacer lo siguiente:

explain (buffers,analyze) select ..... ;

En lo personal el plan lo miro con https://explain.depesz.com/ te
muestra algunas cosas utiles sobre los planes, el hints es basico pero
puede ayudar.  ( puedes anonymitizar el plan si tienes nombres sensibles).
Sobre los indices,  puede que no te hagan falta ahora puede que mas
adelante te hagan falta, crearlos o no crearlos depende de que tan
seguido mires la base. en lo personal estoy probando en mis bases de
datos un proyecto llamada Dexter ( que crea indices de forma automatica
), por lo menos los basicos.

Pegale una mirada si quieres. https://github.com/ankane/dexter

Recuerda que postgresql es una de las bases libres mas avanzada del
mundo y si no usa indices es por que seguramente las saca del buffer o
el costo de usar indices como ya te lo mensionaron es mas alto que hacer
full scan ).
Para terminar, recuerda hacer tuning de tu base con pgtune
https://pgtune.leopard.in.ua/  No pongas mucha RAM solo la que necesites
para que opere bien.  ( al final del postgresql.conf ) y suerte con tus
bases, espero que esta informaci'on sea util para lo que necesites.

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