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.
