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

RE: VACUUM y CLUSTER

From: Manuel Lamas <manuel3w(at)hotmail(dot)com>
To: <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: RE: VACUUM y CLUSTER
Date: 2008-04-23 21:07:47
Message-ID: BLU136-W36E95E104AB29B9A662B6095E30@phx.gbl (view raw or flat)
Thread:
Lists: pgsql-es-ayuda
> Manuel Lamas escribió:
> 
>>> Depende. En 8.1 y anteriores si hay diferencia, en 8.2 y superiores no
>>> hay diferencia.
>> 
>> Estoy con 8.1.4.
>> 
>> En ese caso, es peor en el resultado final si hago VACUUM tabla por tabla ?
> 
> La diferencia que se hace es que no hay incremento en
> pg_database.datfrozenxid, y por lo tanto el sistema creerá que hay
> problemas de desborde del contador de transacciones.

Dicho asi, el problema parece serio.
 
Te explico lo que me pasa a ver si mi idea tiene sentido :
 
Tengo una base de mas o menos 4 G con mucho trafico. 
 
El CLUSTER seguido de un VACUUM toma en total 90 minutos. En general, el proceso bloquea casi todo movimiento en el programa para los usuarios. Mi idea es de dividir el proceso entre las tablas que no paralizan a los usuarios (dejando los usuarios trabajar en el sistema) y las tablas lentas de procesar (desconectando a todos los usuarios durante ese tiempo).
 
De esa forma, en vez de impedir de trabajar a los usuarios durante 90 minutos, tal vez podría hacerlo durante solo 30 minutos (a verificar).
 
Ahora, el hecho que Postgresql crea que hay problemas de desborde del contador de transacciones a causa que pg_database.datfrozenxid no se incrementa, puede tener alguna consecuencia grave... o que consecuencia ?
 
Muchas gracias.
Manuel


_________________________________________________________________
Changez chaque jour en 1000$. Détails sur connectezetgagnez.ca
http://g.msn.ca/ca55/219

Responses

pgsql-es-ayuda by date

Next:From: Alvaro HerreraDate: 2008-04-23 21:21:49
Subject: Re: VACUUM y CLUSTER
Previous:From: Alvaro HerreraDate: 2008-04-23 20:44:22
Subject: Re: VACUUM y CLUSTER

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