El 09/09/2010 20:45, Alvaro Herrera escribió:
Excerpts from Terry Yapt's message of jue sep 09 11:38:41 -0400 2010:
La aproximación tomada por Oracle es que la transacción que modifica la
fila se debe hacer cargo del trabajo de mover la versión antigua al
segmento rollback y demás limpieza. La aproximación de Postgres es que
es mejor dejarlo así y que el proceso que está atendiendo al cliente
pueda retornar lo más rápido posible; y que otro proceso, que no es
de rendimiento crítico para nadie puesto que no tiene un cliente
conectado, se hace cargo de la limpieza.
Originalmente en Postgres tenías que estar haciendo vacuum a mano o vía
crontab, y era bastante complicado o perdías rendimiento. A medida que
autovacuum ha ido mejorando, los problemas han disminuido drásticamente.
La verdad es que visto de esta forma, para mí es claro cuál de las dos
aproximaciones es la mejor.
(Lo otro que ha tenido efecto significativo en el buen rendimiento de
Postgres en esta área es la invención de la funcionalidad HOT, que
permite hacer una especie de vacuum en cada página cuando es necesario,
que es lo que se llama una "poda" de HOT, o "HOT prune". Esto acerca un
poco la aproximación de PostgreSQL a la de Oracle, pues quien está a
cargo de hacer esta limpieza es aquel proceso que quiera examinar la
página en cuestión).
Excerpts from Terry Yapt's message of jue sep 09 11:38:41 -0400 2010:
El 09/09/2010 17:24, Alvaro Herrera escribió:
PostgreSQL (que Oracle no tiene) y que eliminará ese "puntero" (fila vacía).
Efectivamente.Excerpts from Terry Yapt's message of jue sep 09 11:12:15 -0400 2010:
Hola,
OK, como te comentaba esto se hace siempre en Postgres, debido al
concepto del "non-overwriting storage manager".
Entonces creo que la diferencia estriba en el posterior VACUUM deHola,
row-migration, es cuando en Oracle, un UPDATE amplia la cantidad de
información de forma tal que no cabe en el bloque(s) de disco donde
antes se encontraba esa fila. Oracle, mueve toda la fila a una nueva
posición y pone un "puntero" en la ubicación antigua. Con todo lo que
ello conlleva en el futuro.
información de forma tal que no cabe en el bloque(s) de disco donde
antes se encontraba esa fila. Oracle, mueve toda la fila a una nueva
posición y pone un "puntero" en la ubicación antigua. Con todo lo que
ello conlleva en el futuro.
concepto del "non-overwriting storage manager".
PostgreSQL (que Oracle no tiene) y que eliminará ese "puntero" (fila vacía).
La aproximación tomada por Oracle es que la transacción que modifica la
fila se debe hacer cargo del trabajo de mover la versión antigua al
segmento rollback y demás limpieza. La aproximación de Postgres es que
es mejor dejarlo así y que el proceso que está atendiendo al cliente
pueda retornar lo más rápido posible; y que otro proceso, que no es
de rendimiento crítico para nadie puesto que no tiene un cliente
conectado, se hace cargo de la limpieza.
Originalmente en Postgres tenías que estar haciendo vacuum a mano o vía
crontab, y era bastante complicado o perdías rendimiento. A medida que
autovacuum ha ido mejorando, los problemas han disminuido drásticamente.
La verdad es que visto de esta forma, para mí es claro cuál de las dos
aproximaciones es la mejor.
(Lo otro que ha tenido efecto significativo en el buen rendimiento de
Postgres en esta área es la invención de la funcionalidad HOT, que
permite hacer una especie de vacuum en cada página cuando es necesario,
que es lo que se llama una "poda" de HOT, o "HOT prune". Esto acerca un
poco la aproximación de PostgreSQL a la de Oracle, pues quien está a
cargo de hacer esta limpieza es aquel proceso que quiera examinar la
página en cuestión).
Gracias Alvaro.... mucho más claro.
Aunque revisaré más a fondo el asunto de HOT prune, pues tal y como lo
planteas, prefiero el "modo de hacer" de PostgreSQL, a pesar de que
comentas que HOT prune ha tenido un buen efecto en PostgreSQL.
