Skip site navigation (1) Skip section navigation (2)

Re: Tablas no modificables

From: Eduardo Morras <nec556(at)retena(dot)com>
To: Jaime Casanova <jaime(at)2ndquadrant(dot)com>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Tablas no modificables
Date: 2011-05-31 17:33:15
Message-ID: 4D301C9701860620@ (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
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




In response to

pgsql-es-ayuda by date

Next:From: Ing. Esneiker Enriquez CabreraDate: 2011-05-31 18:00:50
Subject: duda con lenguaje plpgsql
Previous:From: Alvaro HerreraDate: 2011-05-31 15:34:36
Subject: Re: Herencia de ctablas y datos

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group