2011/5/30 Eduardo Morras <nec...@retena.com>: > > a) En las tablas viejas sin cambios, se sigue usando mvcc ?
si, pero no escribes en esas tablas no veo que diferencia haga que use o no MVCC > 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 tiene que ver con las funciones que uses si no la cantidad de registros que se van a leer, si haces un sum() o avg() o lo que sea sobre toda la tabla obviamente no va a usar indices > 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. y porque escribir datos sin mvcc es seguro? > d) Es cierto que el principal problema del punto b) es precisamente mvcc? no > e) Serian mas rapidas o solo marginalmente mas rapidas? > > 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 solo se ejecuta en las tablas que cambian, asi que si esas tablas no se mueven no se ejecutara en ellas > 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). > sino quieres bloqueos, no bloquees... el AccessShareLock que es el que usa el SELECT solo bloquea a ExlusiveLock (que no se toma de forma automatica sino solo manual), AccessExclusiveLock (que toma ALTER TABLE, DROP TABLE, TRUNCATE, VACUUM FULL y algun otro que no recuerdo) y hay otro mas pero que tampoco se toma de forma automatica... -- Jaime Casanova www.2ndQuadrant.com Professional PostgreSQL: Soporte y capacitación de PostgreSQL - 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
