Re: Entendiendo la version 8.0

--- Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> escribió:

> 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.
> [...]
> Por otra parte, internamente se usan savepoints para
> implementar
> EXCEPTIONs en PL/pgSQL (y con un poco de suerte,
> prontamente en otros
> lenguajes tambien).
>
Mira tu, esto me resulto interesante.

Aun asi me gustaria encontrar otros ejemplos, voy a
hacer un google a ver si encuentro algo especifico.

>
> > 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.
>
Este es un buen punto.

> 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.
>
Aunque se supone que toda base de datos debe tener
este proceso (es parte de la idea de evitar escrituras
a discos lo mas posible) no todas tienen la precaucion
de optimizar esto. Informix literalmente detiene la
ejecucion de todas las consultas cada vez que llegas a
un checkpoint.
Punto a favor.

> 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.
>
Este ciertamente es nuevo para mi, ahora entiendo de
que se trata. Aunque la verdad voy a evitar
mencionarlo. ;)

atentamente,
Jaime Casanova

_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com