Re: Información: row migration, row chaining, etc....

El 09/09/2010 20:45, Alvaro Herrera escribió:
> Excerpts from Terry Yapt's message of jue sep 09 11:38:41 -0400 2010:
>> El 09/09/2010 17:24, Alvaro Herrera escribió:
>>> Excerpts from Terry Yapt's message of jue sep 09 11:12:15 -0400 2010:
>>>
>>> Hola,
>>>
>>>>> 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.
>>> 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 de
>> PostgreSQL (que Oracle no tiene) y que eliminará ese "puntero" (fila vacía).
> Efectivamente.
>
> 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.