Hola Carlos, On Mon, Sep 2, 2019 at 3:24 PM Carlos T. Groero Carmona <cton...@gmail.com> wrote:
> Hola lista, > > Estaba revisando una consulta que esta tomando mucho tiempo 304ms y al > revisar el explain no utiliza ninguno de los indexes que existen. > > La consulta es esta: > > Select mobile_users.* from mobile_users where org_id = 1; > > Si bien es cierto que ninguno de los indexes que existen para esa tabla > tiene solo la columna org_id, todos los indexes son compuestos es decir > utilizan multiples columnas donde en casi todos se incluye org_id. > > Hay uno que tiene dos columnas org_id y la fecha en que se creo el > usuario, sin enbargo postgres nunca utiliza ese index parcialmente, > prefiere utilizar el scaneo sequencial. > > En este caso, el 99.98% de la information pertenece a org_id =1 pero 304ms > es demasiado lento para servidor con 64CPU y 512GB de RAM y solo 356mil > rows. > > En fin despues de comentarles el entornondonde se ejecuto esa consulta, me > pregunto: si postgre decidiera utilizar un index en vez de scaneo > sequencial, podria utilizar el index que le comente donde se indexa por > org_id y la fecha en que se creo la columna, aunque solo se pase el org_id > en la consulta? > Si org_id = 1 en 99,98% de los casos, es muy probable que el optimizador de consultas considere que que el índice es una pérdida de tiempo y si la fecha de creación no se usa en el where, bien poco aportará. Prueba definiendo un rango de fechas de creación, o org_id = 0, y es probable que la cosa cambie. > Este es el resultado del explain analyze: > Seq Scan on mobile_users (cost=0.00..38533.34 rows=356403 width=9015) > (actual time=0.022..292.568 rows=356409 loops=1) > Filter: (org_id = 1) > Rows Removed by Filter: 18 > Planning time: 2.292 ms > Execution time: 304.003 ms > > Gracias de antemano por sus comentarios. > Carlos > > -- Olivier Gautherot https://www.linkedin.com/in/ogautherot/ On Mon, Sep 2, 2019 at 3:24 PM Carlos T. Groero Carmona <cton...@gmail.com> wrote: > Hola lista, > > Estaba revisando una consulta que esta tomando mucho tiempo 304ms y al > revisar el explain no utiliza ninguno de los indexes que existen. > > La consulta es esta: > > Select mobile_users.* from mobile_users where org_id = 1; > > Si bien es cierto que ninguno de los indexes que existen para esa tabla > tiene solo la columna org_id, todos los indexes son compuestos es decir > utilizan multiples columnas donde en casi todos se incluye org_id. > > Hay uno que tiene dos columnas org_id y la fecha en que se creo el > usuario, sin enbargo postgres nunca utiliza ese index parcialmente, > prefiere utilizar el scaneo sequencial. > > En este caso, el 99.98% de la information pertenece a org_id =1 pero 304ms > es demasiado lento para servidor con 64CPU y 512GB de RAM y solo 356mil > rows. > > En fin despues de comentarles el entornondonde se ejecuto esa consulta, me > pregunto: si postgre decidiera utilizar un index en vez de scaneo > sequencial, podria utilizar el index que le comente donde se indexa por > org_id y la fecha en que se creo la columna, aunque solo se pase el org_id > en la consulta? > > Este es el resultado del explain analyze: > Seq Scan on mobile_users (cost=0.00..38533.34 rows=356403 width=9015) > (actual time=0.022..292.568 rows=356409 loops=1) > Filter: (org_id = 1) > Rows Removed by Filter: 18 > Planning time: 2.292 ms > Execution time: 304.003 ms > > Gracias de antemano por sus comentarios. > Carlos > > >
