Horacio muchas gracias por tu aporte, tal como decís, ahora no usa los índices, pero si sigue creciendo la base, posiblemente mas adelante los usará y andará mejor. Usé varios de los visualizadores online, son muy buenos. Buenísimo lo de tu proyecto Dexter. Le voy a echar un vistazo.
Uso bastante pgtune, pero, sirve para bases de datos en cloud como google sql (postgres) ? El mar, 7 jun 2022 a las 17:36, Horacio Miranda (<hmira...@gmail.com>) escribió: > 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/ >>>> "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) >>>> >>>
