Re: Optimización de consulta

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 (<hmiranda(at)gmail(dot)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 (<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/
>>>> "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)
>>>>
>>>