Hola: Revisa este tutorial:
http://www.postgresqltutorial.com/postgresql-indexes/postgresql-multicolumn-indexes/#targetText=Introduction%20to%20PostgreSQL%20multicolumn%20indexes,index%2C%20or%20a%20concatenated%20index. Saludos. El lun., 2 sept. 2019 a las 15:07, Carlos T. Groero Carmona (< cton...@gmail.com>) escribió: > Creo que yo mismo puedo responder a esta pregunta despues de hacer algunas > pruebas. > > Scenario 1: trate de forzar el uso del index pasando una fecha: > Select mobile_users.* from mobile_users where org_id = 1 and created > > '2010-01-01 00:00:00'; > Postgres decidio no usar el index. > > Scenario 2: utilize la misma consulta pero cambie el org_id por uno de los > que menos usuarios tiene (solo 2 usuarios) > Select mobile_users.* from mobile_users where org_id = 2 and created > > '2010-01-01 00:00:00'; > Postgres utilizo el index del que le estaba hablando > > Scenario 3: Elimine la fecha de la consulta > Select mobile_users.* from mobile_users where org_id = 2 > Postgres utilizo el mismo index y solo le tomo 0.12ms > > Asi que si, postgres utiliza los indexes "partialmente", los indexes > regulares con columnas multiples pueden ser utilizados por postgres aunque > no se utilize todas las columas del index en la consulta... > > Como siempre seria genial escuchar otras opiniones y experiencias. > > Gracias, > Carlos > > On Mon, Sep 2, 2019 at 2: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 >> >> >> -- Roberto Andrade Fonseca
