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.

Un saludo y gracias.

Search Discussions

  • Alvaro Herrera at Sep 7, 2010 at 9:48 pm

    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.

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Terry Yapt at Sep 9, 2010 at 3:12 pm
    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.
  • Alvaro Herrera at Sep 9, 2010 at 3:25 pm
    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".
    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.
    Esto no existe en Postgres. Un registro existe siempre en un solo
    bloque. Los registros que ocupan más que un bloque son "comprimidos"
    usando TOAST: los atributos demasiado grandes se guardan automáticamente
    en una tabla aparte (la tabla toast), y en el registro propiamente tal
    sólo se guarda un puntero hacia ese otro registro. Este puntero mide
    como 20 bytes. Por lo tanto una de las limitaciones de Postgres es que
    la cantidad de columnas que puede tener un registro es la cantidad que
    se puede almacenar en un solo bloque. Con tipos de datos pequeños
    puedes tener 1600 columnas en bloques de 8kB (el tamaño por omisión).
    Si los datos requieren un puntero toast, entonces la cantidad de
    atributos es menor (creo que puedes tener hasta 200 y tantas columnas).

    Hay una explicación más detallada de TOAST en el manual.

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Terry Yapt at Sep 9, 2010 at 3:38 pm

    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).
  • Alvaro Herrera at Sep 9, 2010 at 6:45 pm

    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).

    --
    Álvaro Herrera <alvherre@commandprompt.com>
    The PostgreSQL Company - Command Prompt, Inc.
    PostgreSQL Replication, Consulting, Custom Development, 24x7 support
  • Terry Yapt at Sep 10, 2010 at 10:47 pm

    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-es-ayuda @
categoriespostgresql
postedSep 7, '10 at 3:29p
activeSep 10, '10 at 10:47p
posts7
users2
websitepostgresql.org.es
irc#postgresql

2 users in discussion

Terry Yapt: 4 posts Alvaro Herrera: 3 posts

People

Translate

site design / logo © 2022 Grokbase