Re: Estructura de una página Postgresql

From: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
To: silv silv <silviline1(at)yahoo(dot)es>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Estructura de una página Postgresql
Date: 2004-10-19 16:26:59
Message-ID: 20041019162659.GA4171@dcc.uchile.cl
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

On Tue, Oct 19, 2004 at 06:06:06PM +0200, silv silv wrote:

Hola,

> infomask: 0x0512 ==> Si es 0x0512, está borrado.
> (HASVARWIDTH|HASOID|XMIN_COMMITTED|XMAX_COMMITTED) ==>
> Si la última opción es XMAX_COMMITED, está borrado.
>
> infomask: 0x0912 ==> Si es 0x0912, no está borrado.
> (HASVARWIDTH|HASOID|XMIN_COMMITTED|XMAX_INVALID) ==>
> Si la última opción es XMAX_INVALID, no está borrado.

Y que pasa con XMIN_INVALID, por ejemplo?

Ojo con Xmin y Xmax, que son los que indican que la tupla esta viva o
no. Si XMIN_INVALID, quiere decir que la transaccion que creo la tupla
se aborto o aun no ha terminado (==> la tupla no es visible). En caso
contrario, puede ser que se haya marcado XMIN_COMMITTED pero no es
obligatorio, porque la transaccion que crea la tupla no pone ese bit,
sino que lo pone una transaccion posterior que visite la tupla y haya
determinado que la transaccion que creo la tupla efectivamente fue
comprometida (commit).

Idem con Xmax, que es la transaccion que borra la tupla. Si es INVALID,
entonces dicha transaccion aborto o aun no ha completado (==> la tupla
es visible). Si es COMMITTED, entonces esta comprometida y la tupla no
es visible. Aplica lo mismo anterior: puede que la transaccion haya
comprometido pero si nadie ha visitado la tupla despues de eso, entonces
no tendra el flag XMAX_COMMITTED, pero tampoco tendra XMAX_INVALID.

Ojo tambien con XMAX_MARKED_FOR_UPDATE, porque tambien setea el Xmax de
la tupla pero con otro proposito (SELECT ... FOR UPDATE).

Te recomiendo mirar src/backend/include/access/htup.h, que es donde se
definen estos flags. Creo que en src/backend/utils/time/tqual.c esta
explicado el sistema de visibilidad. Tambien mira
src/backend/access/transam/README en los fuentes de 8.0, ahi se explica
algo sobre el sistema de transacciones y la visibilidad. Ojo que ese
archivo no existe en versiones anteriores.

> He intentado estudiar el comportamiento para los
> archivos de índices (en concreto un índice B+) y dicha
> información no se visualiza, con lo que no tengo
> manera de saber si la tupla está borrada/no

No. Los indices no llevan informacion de visibilidad. Para saber si
una tupla esta viva o no tienes que consultar el heap(*). Un par de
razones para esto:

- el indice seria mucho mas gordo si tuviera que llevar esa informacion
(==> peor rendimiento)

- actualizar esa informacion en el indice es dificil porque estaria
duplicada o mas (considera que una tabla puede tener varios indices, y
habria que actualizar todos los punteros a una tupla), lo cual
facilmente puede llevar a deadlocks

- Ademas, habra problemas de rendimiento por tener que acceder a
multiples relaciones simultaneamente.

Me pregunto para que quieres saber toda esta informacion?

(*) de hecho un indexscan visita el indice, obtiene una tupla, luego
visita el heap y la examina; si el heap dice que la tupla esta viva
entonces se retorna hacia afuera. Si no, se descarta y se continua con
la siguiente tupla en el indice. Naturalmente, las multiples versiones
(MVCC) de una tupla tienen cada una un puntero en el indice. Por este
motivo es que no se pueden acelerar algunas funciones de agregacion, por
ejemplo.

Suerte,

--
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Amanece. (Ignacio Reyes)
El Cerro San Cristóbal me mira, cínicamente, con ojos de virgen"

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2004-10-19 16:38:59 Re: Problemas con PGMail
Previous Message Cancino 2004-10-19 16:11:18 Re: Problemas con PGMail