Re: Documento de Postgresql Internal

Edwin Quijada escribió:

> >- implementacion de candados compartidos a nivel de tuplas. Esto sirve
> > para impedir los deadlocks con llaves foraneas. La manifestacion a
> > nivel de SQL de esto es una clausula FOR SHARE (en comparacion al FOR
> > UPDATE que toma un candado exclusivo en la tupla).
>
> Quiere decir, que es mejor usar FOR SHARE que FOR UPDATE , debemos
> cambiarlo?
> Supongo q si?

Bueno, son cosas distintas. Si tu aplicacion hace FOR UPDATE y necesita
el lock en la tupla, entonces dejalo asi. Las llaves foraneas estaban
haciendo FOR UPDATE pero en realidad no necesitaban tanto, y por eso
tenian problemas. Para solucionar esa situacion particular es que
invente el FOR SHARE.

> >- integre el autovacuum en postmaster
> Segun lei, en esta version esto ha mejorado mucho con respecto a la 8.0.4 ,
> la pregunta es en pos.conf se puede especificar el tiempo cuando se va
> hacer o el lo hace cuando el lo cree necesario?
> Actualmente sigo haciendolo en tareas del cron,pero esto en 8.0.4

No puedes especificar el tiempo en que se va a hacer, pero puedes
especificar umbrales de cantidad de tuplas insertadas/modificadas/
eliminadas para que se haga. Y tambien puedes establecer valores de
vacuum_delay para cada tabla.

Eventualmente tendria que haber una manera de especificar los tiempos,
"ventanas administrativas" y demas, pero alguien tiene que hacer el
trabajo. Creo que no es de mi interes y por lo tanto no lo hare (a
menos que alguien tenga mucho interes y quiera financiarlo).

> >Tambien aparezco como autor en two-phase commit pero en realidad lo
> >unico que hice fue limpiar un poco el parche de Heikki Linnakangas, que
> >despues tomó Tom Lane y le hizo bastantes otras mejoras.
>
> Puedes explicar un poco mas a fondo el 2PC

Este tema da para largo asi que lo dejo para despues.

--
Alvaro Herrera http://www.amazon.com/gp/registry/CTMLCN8V17R4
"No deja de ser humillante para una persona de ingenio saber
que no hay tonto que no le pueda enseñar algo." (Jean B. Say)