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
(<asotolo...@gmail.com>) escribió:
Hola
El mar., 7 de junio de 2022 2:08 p. m., Guillermo E. Villanueva
<guillermo...@gmail.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
(<alvhe...@alvh.no-ip.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)
