Skip site navigation (1) Skip section navigation (2)

Re: Estructura de una página Postgresql

From: silv silv <silviline1(at)yahoo(dot)es>
To: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Cc: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: Estructura de una página Postgresql
Date: 2004-10-22 09:06:35
Message-ID: 20041022090635.95096.qmail@web50101.mail.yahoo.com (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
Álvaro,
 
no he dicho nada, disculpa.
 
Gracias por tu valiosa aportación. Estoy estudiando en la línea que me propusiste.
 
Gracias nuevamente por tu ayuda,
 
Sílvia


Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl> wrote:
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 ()
"Amanece. (Ignacio Reyes)
El Cerro San Cristóbal me mira, cínicamente, con ojos de virgen"


		
---------------------------------

In response to

pgsql-es-ayuda by date

Next:From: Martin MarquesDate: 2004-10-22 11:09:39
Subject: Re: Indice para columna date
Previous:From: Sanchez Escobedo JorgeDate: 2004-10-22 06:42:19
Subject: Re: manual (perdon)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group