Re: No hacer vavum a ciertas tablas.

Mauricio:

Lo primero, tu correo me ha llegado solo a mi direccion. La costumbre
en las listas de postgres es contestar a la lista y, opcionalmente,
añadir a los interesados. De esta manera toda la gente lo ve y si hace
falta los interesados reciben copia en el inbox para que salte mas.
Los MUA actuales son muy buenos eliminando duplicados ( a mi por
ejemplo me los pone todos en la lista el gmail ). Añado a la lista en
esta respuesta.

2018-01-11 4:08 GMT+01:00 mauricio pullabuestan <jmauriciopb(at)yahoo(dot)es>:
...
> Francisco, si la tabla solo se hace insert, pero me di cuenta que postgres realizo vacuum sobre la tabla y mi preocupación fue consumir recursos en esa tabla si no necesito un vacuum, pero lo que pude leer el costo del vacuum para esta tabla es minimo y por lo que no vale la pena quitarle el autovacuum.
> No tengo claro que hace el freezing, puedes explicarme un poco

El autovacuum NO ejectua si no lo necesita. Cuando dices "postgres
realizo el vacuum" me imagino que quieres decir "el autovacuum realizo
un vacuum".

Te explico un poco. Postgres es todo el sistema, no sabemos a que
parte de el te refieres. La parte principal es el servidor de la BD,
que son los procesos que responden al socket y ejecutan las queries,
una de las cuales es el vacuum, que si la mandas la ejecuta.
Cualquiera ( si los permisos lo permiten ) puede conectarse y ejecutar
un "VACUUM tabla" y el servidor lo ejecuta. Otra parte es del demonio
de autovacuum, que es un procesito que arranca, monitoriza la
actividad en als tablas ( ayudado por unas estadisticas que se
recolectan por varios sitios ) y, si lo considera necesario ( pilotado
por lo que ve en las estadisticas y unas tablas de control ), ejecuta
un comando VACUUM ( que para la parte de ejecucion de queries es casi
como cualquier otro, de hecho hace no tanto tiempo el autovacuum era
un programita aparte, y antes de eso la gente usaba diversos scripts
). Por esto es importante que si te refieres al automatico cuando
preguntes digas "el postgres realizo un vacuum AUTOMATICO de la
tabla", o algo asi, para precisar.

Si se te realizo un vacuum automatico hay dos posibilidades, o habias
modificado ( update/delete, como te dije insert no cuenta ) la tabla
en alguna prueba y lo olvidaste o habia pasado mucho tiempo. Es bueno
que te lo haga, y hay viene muy bien el automatico, ya que si tienes,
como yo p.e., una tabla de registros que es insert only pero un dia
tienes que hacer un delete porque añadiste dos veces el mismo lote,
p.e., o tienes que hacer un update porque metiste algun campo mal, el
automatico lo ve y te hara el vacuum, y una vez hecho borra los
contadores y no la volvera a tocar. Ademas el vacuum pesa poco, esta
muy optimizadito para no joder, y yo aun no me he encontrado con una
tabla que necesite quitarselo.

Ahi una tercera posibilidad, que te estuviera haciendo un ANALYZE para
actualizar las estadisticas. El analyze va parcialmente integrado con
el vacuum, de hecho el autovacuum hace auto-analyze tambien. Y, salvo
que sepas bien lo que haces y tus tablas sean rara, es mejor que lo
dejes, si no tus estadisticas se quedaran viejas y tus queries pueden
sufrir mucho.

Lo del freezing. Postgres utiliza una cosa que se llama MVCC, Multi
Version Concurrency Control. Para eso va numerando correlativamente
las transacciones y apunta en cada fila que crea la transaccion que la
creo, para saber que otras transacciones pueden verla. Cuando tiene
que borrar ( recuerda que update ~= insert + delete ) apunta en la
fila borrada que transaccion la borro.

De esta forma una transaccion con numero N sabe que ve todas las filas
en las que la transaccion de creacion ( que siempre existe ) es <= N y
la transaccion de borrado ( que es opcional ) es >=N o inexistente.

Todo esto esta muy bien, pero los numeros de transaccion tienen un
numero finito de bits, y las transacciones pueden dar overflow. Para
evitar eso postgres usa un sistema circular, o modular, algo asi como
que si el numero fuera de 1 a 1000 y la actual es la 300 las 499 por
delante de la actual, de 301 a 799 estan en el futuro, y las 499 por
detras, de 1 a 299 y de 801 a 1000, en el pasado.

Lo que esta muy bien, pero si no tocas una fila en mucho tiempo tendra
problemas de que el numero de transacciones se de la vuelta, la pille,
como cuando doblan a alguien en una carrera. Para eso esta el
freezing. Cogemos un valor especial, 0 por ejemplo, que simboliza que
una fila es muy vieja, y si la transaccion se lleva, p.e., 100 con la
actual, la ponemos en un paso de vacuum a cero. En mi ejemplo anterior
pondriamos a cero todas de 801 a 1000 y de 1 a 199. Ya no la pueden
pillar. Y cambias la logica de "anterior" a las 499 por detras o cero.
Si no haces eso tienes problemas. Gordos. De hecho postgres lleva la
cuenta de cual es la edad de la transaccion mas antigua y si se acerca
mucho a la actual entra en un modo que se solo te deja entrar para
arreglar eso, y es desagradable.

En general yo te recomandaria que si no tienes bien claro como
funciona el autovacuum / autoanalyze lo dejes puesto por defecto.
Mirate un poco los capitulos relevantes de la documentacion, y ajusta
si quieres los parametros de cada tabla si tienes tablas especiales. Y
quitalo solo para casos especiales y cuando sepas muy bien lo que
estas haciendo. Yo llevo usando postgres desde antes de que se llamase
postgreSQL, y jamas he quitado el autovacuum desde que se invento, lo
mas que he hecho ha sido tunearlo con la tabla de control y diseñar
mis BD de forma que necesiten menos vacuum ( p.e. usando para tablas
tipo "insert only" de esas particiones que pueden llevarse un buen
vacuum manual al archivarlas y ya no las toca nunca ).

Francisco Olarte.