Re: [pgsql-es-ayuda] Separación lógica de tablas, agrega rendimiento?

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(dot)perales(at)gmail(dot)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 <alvherre(at)2ndquadrant(dot)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.