Re: Tablas no modificables

At 23:14 30/05/2011, Jaime Casanova wrote:
>2011/5/30 Eduardo Morras <nec556(at)retena(dot)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

O sea, cuando hago un select de este tipo

SELECT COUNT() FROM Tabla1 WHERE (id>=1000 AND id<=9999)

y existe un indice en Tabla1 por el campo id, se
usa dicho indice para acelerar la consulta?

Tenia entendido precisamente que no, que hay que
hacer un tablescan porque el usar mvcc impide
conocer en el indice que filas/registros estan
activos para la consulta actual y cuales
pertenecen a otras transacciones anteriores y
pueden mostrar datos borrados o actualizados.

> > 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?

Es seguro escribir una vez para llenar la tabla,
luego la usare como diccionario estatico que no
admitira mas que consultas SELECT.

> > 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

Opss tienes toda la razon, no habia pensado en eso.

> > 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

Eduardo Morras