On 05/30/2011 12:58 PM, Eduardo Morras wrote:
Muy buenas a todos.
Actualmente tengo una tabla con muchos registros y quiero
particionarla, una parte con datos de meses anteriores que no van a
cambiar, y otra con el mes actual. Se como hacer la particion y las
consultas posteriores, pero mis dudas son:
a) En las tablas viejas sin cambios, se sigue usando mvcc ?
El sistema MVCC de PostgreSQL está por algo: es el que garantiza la
consistencia de los datos, y esto, creéme es sumamente importante, por
lo que no hay forma de que puedas desabilitarlo o algo por el estilo.
b) Al hacer consultas tipo OLAP con un monton de funciones agregadas,
es cierto que no se pueden usar los indices y hay que hacer un
table-scan completo para calcularlas?
No, si se pueden crear índices en la columa que usaste para particionar.
Mira un pequeño ejemplo:
-- Crea la tabla maestra
CREATE TABLE shipment (
id SERIAL PRIMARY KEY,
address TEXT NOT NULL,
shipping_date TIMESTAMP NOT NULL);
-- Tablas hijas
CREATE TABLE shipment_part_2008 (
CHECK (shipping_date >= DATE '2008-01-01'
AND shipping_date < DATE '2009-01-01')
) INHERITS (shipment);
CREATE TABLE shipment_part_pre2008 (
CHECK (shipping_date < DATE '2008-01-01')
) INHERITS (shipment);
-- Crea los indices en la shipping_date para acelerar las búsquedas
CREATE INDEX shipping_date_2008 ON shipment_part_2008 (shipping_date);
CREATE INDEX shipping_date_pre2008 ON shipment_part_pre2008 (shipping_date);
c) Existen tablas en postgres que no usen mvcc? Solo quiero escribir
datos en ellas o (o exclusivo) leer datos de ellas, por lo que no
seria necesario mvcc.
Como ya te dije, no existe algún parámetro (al menos que yo conozca) que
te permita activar o desactivar MVCC, porque no sería para nada ni
factible ni recomendable. En la nueva versión beta de 9.1, existe algo
llamado "Unlogged Tables", que no son más que las tablas que no quieres
que vayan al log de escritura adelantada(WAL) y pueden actuar como un
tabla en memoria, pero esto no es aconsejable para tablas que
constituyan una pieza clave de tu negocio.
d) Es cierto que el principal problema del punto b) es precisamente mvcc?
e) Serian mas rapidas o solo marginalmente mas rapidas?
La rapidez de las consultas depende de muchos factores, no sólo de MVCC:
- hardware disponible
- optimización del servidor
- funcionar usar
- formas de escritura de la consulta, etc
Creo que para las consultas de tipo OLAP, las funciones ventana y las
funciones de recursividad son la clave.
Para mi seria perfecto que existieran esas tablas, tampoco seria
necesario autovacuum ya que los datos son fijos aunque supongo que si
hara falta el analyze.
Autovacuum lo puedes desactivar cuando quieras. Para esto está
autovacuum = on/off
Espero que se entienda lo que necesito, convertir las tablas que se
que no se van a modificar en una tabla constante tipo
WriteOnce-ReadMany sin los costes de administracion interna de
postgres (ni bloqueos, ni locks, ni nada similar).
Un saludo
-
Enviado a la lista de correo pgsql-es-ayuda
(pgsql-es-ayuda@postgresql.org)
Para cambiar tu suscripción:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
--
Marcos Luis Ortiz Valmaseda
Software Engineer (Distributed Systems)
http://uncubanitolinuxero.blogspot.com
