Disculpen me equivoque, la consulta es así: select count(e.*) from cajas e left join material m on m.id = e.material_id where m.cliente_id = 10
2016-04-19 17:23 GMT-05:00 Ivan Perales M. <ivan.pera...@gmail.com>: > Bueno, ese no necesariamente lo entiendo como a veces sí y a veces no, > supongo va a depender de los casos de uso que vaya a tener el sistema. > Y si no es mucho abusar, en cuantos registros buscaría postgres si se hace > la sig consulta: > Tenemos las siguientes 3 tablas, cliente, material (que contiene > cliente_id) y cajas (que contiene material_id) > La tabla cajas tiene 1 millón de registros. > > select count(e.*) from cajas e > left join material m on m.id = e.material_id > where cl.id = m.cliente_id > > Ya que el filtro no es directamente sobre la tabla cajas, tendrá que hacer > el join primero y luego ya con el index por defecto que tiene cliente_id > hacer el filtrado, pero para hacer el join hay que recorrer primero todo el > millón de registros no? > Explain me arroja esto en particular: > Aggregate (cost=14659.91..14659.92 rows=1 width=146) > -> Hash Join (cost=303.13..14656.84 rows=1230 width=146) > Hash Cond: (e.material_id = m.id) > -> Seq Scan on caja e (cost=0.00..12652.84 rows=450284 width=150) > -> Hash (cost=301.89..301.89 rows=99 width=4) > -> Bitmap Heap Scan on material m (cost=5.18..301.89 > rows=99 width=4) > Recheck Cond: (client_id = 10) > -> Bitmap Index Scan on material_client_id_key1 > (cost=0.00..5.16 rows=99 width=0) > Index Cond: (client_id = 10) > > > El Seq Scan me da a entender que efectivamente recorrerá primero todos los > registros de la tabla cajas. > > 2016-04-19 16:44 GMT-05:00 Alvaro Herrera <alvhe...@2ndquadrant.com>: > >> Ivan Perales M. escribió: >> > Vamos a suponer que dejo los indices adecuados para las consultas mas >> > comúnes en una sola tabla. Todo es perfección hasta que el usuario dice, >> > necesito poder filtrar por todas las columnas, que haces? agregas >> indices >> > en cada una? >> >> No. Cuando eso pasa simplemente dejas que el sistema escoja la mayor >> cantidad de índices que pueda y para el resto filtra los resultados >> usando el resto de las condiciones. No necesitas índices en todas las >> columnas ni en todas las combinaciones, sólo en las más selectivas. >> >> Por otro lado, si instalas un índice BRIN en todas las columnas, las >> búsquedas se limitarán "automáticamente" a recorrer sólo los rangos de >> páginas que cumplan todas las condiciones. >> >> > y si filtra por dos o tres columnas de cualquier combinacion, >> > como prevees esta consulta para crear los indices adecuados? >> >> Postgres puede "mezclar" índices usando bitmaps. Es una técnica muy >> efectiva. >> >> > No seria mejor combinar la separación por schema y la implementación de >> > indices adecuadamente? >> >> No necesariamente. >> >> -- >> Álvaro Herrera http://www.2ndQuadrant.com/ >> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services >> > > > > -- > Lindolfo Iván Perales Mancinas > Solo existen 10 tipos de personas en el mundo, las que saben binario y las > que no. > -- Lindolfo Iván Perales Mancinas Solo existen 10 tipos de personas en el mundo, las que saben binario y las que no.
