Hola: Debes hacer un nuevo índice que solamente utilice el campo org_id.
Inténtalo y nos comentas. Saludos. El lun., 2 sept. 2019 a las 14:24, Carlos T. Groero Carmona (< cton...@gmail.com>) escribió: > 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