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

From: "Ivan Perales M(dot)" <ivan(dot)perales(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Ayuda Esp PostgreSQL <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: [pgsql-es-ayuda] Separación lógica de tablas, agrega rendimiento?
Date: 2016-04-19 22:23:46
Message-ID: CAHMuS04A=LbmgBj0Fic0dc2Kquobj429j5++-cpLH1Z6bmtqug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

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.

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Ivan Perales M. 2016-04-19 22:25:00 Re: [pgsql-es-ayuda] Separación lógica de tablas, agrega rendimiento?
Previous Message Alvaro Herrera 2016-04-19 21:44:50 Re: Separación lógica de tablas, agrega rendimiento?