Re: Entendiendo la version 8.0

On Mon, Jan 17, 2005 at 02:27:52PM -0600, Jaime Casanova wrote:

Hola,

> Bueno, primero me podrias ayudar con un ejemplo
> practico de en que situacion serian util los
> savepoints ya que vamos a darle fama hay que estar
> preparado a responder lo que a uno le pregunten.

Hmmm ... interesante pregunta. La idea es usarlos cuando llevas ya un
bueno poco de procesamiento en una transaccion, y de pronto decides que
no quieres hacer la ultima parte. En el caso en que tengas dos
alternativas de operacion, dependiendo del estado de la BD:

- si encuentro un registro en la tabla foo, inserto en la tabla B
- si no, inserto en foo, luego inserto en B

entonces pones un savepoint, intentas la alternativa 1, si falla
intentas la otra (o al reves). Sin savepoints hay una condicion de
carrera que es insalvable (este caso particular se puede resolver con
MERGE, introducido en sql2003, que no esta soportado por Postgres -- se
pueden construir ejemplos arbitrariamente complejos, donde necesitas
savepoints).

Por otra parte, internamente se usan savepoints para implementar
EXCEPTIONs en PL/pgSQL (y con un poco de suerte, prontamente en otros
lenguajes tambien).

> Mejoras en el Manejo de la Memoria y E/S: El uso de
> discos y memoria ha sido optimizado mediante el uso
> del algoritmo de «Reemplazo Adaptativo de Cache»
> (ARC), el nuevo escritor en segundo plano y la nueva
> característica de retardo de la recolección de basura
> (vacuum). Esto producirá cargas más predecibles y un
> desempeño sustancialmente más consistente durante los
> períodos de uso intensivo.

Aqui hay tres cosas:
- ARC
- el bgwriter (background writer)
- vacuum delay

El "vacuum delay" es una siestecita que se toma el proceso que esta
haciendo vacuum cada cierto numero de paginas. Esto sirve para no
interferir de manera escandalosa en el I/O de otros procesos; no es una
mejora de rendimiento, es una mejora de predecibilidad. Tus otros
procesos no se van a poner infinitamente lentos porque haya un vacuum.
Ese es un problema real en versiones actuales.

El bgwriter es un proceso independiente que se encarga de escribir las
paginas a disco de vez en cuando, entre checkpoints. En versiones
anteriores, en cada checkpoint tenias una "tormenta de I/O" y el
rendimiento bajaba drasticamente en ese punto. La idea del bgwriter es
distribuir ese I/O a traves del tiempo.

ARC es una nueva estrategia para manejo mas efectivo de la memoria cache
(shared_buffers). La estrategia anterior, LRU, es demasiado simplista;
en particular, si de pronto alguien hace un seqscan de una tabla
gigante, todo lo que habia en cache se pierde; y traes a cache _todas_
las paginas de la tabla grande, que posiblemente no van a ser necesarias
despues de que termine el seqscan. Por lo tanto, doble trabajo perdido.

--
Alvaro Herrera (<alvherre[(at)]dcc(dot)uchile(dot)cl>)
"This is a foot just waiting to be shot" (Andrew Dunstan)