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

Hola Alvaro, perdona el retraso, he estado de viaje....

Bueno, explicado de una forma rudimentaria (por no extenderme sobre
Oracle en una lista de PostgreSQL):

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.

row-chaining, es cuando una fila no cabe en un solo bloque de disco
lógico (blocksize) con el tamaño con el que se ha definido la base de
datos (en el momento de su creación o de la creación de sus datafiles),
por tanto, en ese momento, Oracle debe guardar esa fila en más de un
bloque lógico de información y esto es lo que se denomina row-chaining.
En el futuro, dependiendo de que información deseemos recoger de la
fila, Oracle deberá ir de un bloque a otro o no.

Y por último, el problema del borrado de filas y su posible (o no)
sustitución por otras nuevas. Algo que también afecta al rendimiento y
que genera una mezcla de los dos problemas anteriores:
row-chaining-migration.

Si alguien tiene más interés en este aspecto, aquí lo explican muy bien:

http://www.akadia.com/services/ora_chained_rows.html

Gracias Alvaro...

El 07/09/2010 23:48, Alvaro Herrera escribió:
> Excerpts from Terry Yapt's message of mar sep 07 10:58:56 -0400 2010:
>> Buenos dias,
>>
>> estoy buscando información sobre lo que, en Oracle, se denomina
>> row-migration, row-chaining, etc.... Pero aplicado a PostgreSQL.
>>
>> Es decir, pretendo averiguar como afecta a una base de datos PostgreSQL
>> una mala planificación de su FillFactor, como afectan las updates y
>> deletes sobre las tablas y como se pueden mitigar los problemas que
>> puedan acarrear.
> No sé mucho de Oracle. ¿Qué son row-migration y row-chaining,
> exactamente?
>
> Ten en cuenta que Oracle usa un "overwriting storage manager", es decir,
> un registro modificado ocupa la misma posición física que el original, y
> este original se mueve al "rollback segment". En contraste, Postgres
> usa un "non-overwriting storage manager", en el cual la nueva copia del
> registro ocupa una nueva posición en la tabla y el original sigue
> presente, con un puntero al nuevo (hasta que VACUUM, o la "poda" de HOT
> reciclan el espacio que ocupaba el original).
>
> El fillfactor afecta directamente lo bien que puede trabajar HOT; creo
> que la documentación describe esto en cierto detalle. Conversamente,
> fillfactor no tiene gran efecto sobre VACUUM.
>