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 <jmaurici...@yahoo.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.
