Re: Indexes parciales

Hola Carlos,

On Mon, Sep 2, 2019 at 3:24 PM Carlos T. Groero Carmona <ctonetg(at)gmail(dot)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 <ctonetg(at)gmail(dot)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
>
>
>