Re: OT - Borrar y cargas datos cada mes

Excerpts from Miguel Beltran R.'s message of lun abr 09 17:11:21 -0300 2012:
> Hola lista, perdon por el off-topic
>
> Necesito actualizar una tabla cada mes, esta información me la proporciona
> una entidad externa en un archivo de texto delimitado por pipe ( | ).
> Quiero automatizar el sistema de subir la información pero tengo duda de
> que metodo seria mejor.
>
>
> Unos datos importantes antes:
>
> -El archivo tiene unos 2,500,000 registros y sigue aumentando.
>
> -Aunque en general solo va aumentando la información, tambien existen
> cambios: si el registro X en la columna A tenia 123 y en la columna B tenia
> ABC o sea "X (123,ABC)" , el siguiente mes puede que el registro X cambia
> la columna B y tenga FG1 "X (123, FG1)"; y el registro Y en la columna A
> tenga 410 y en la columna B tenga ABC o sea "Y (410,ABC)" por eso en lugar
> de buscar las diferencias mejor vuelvo a subir todo.
>
> -La tabla en cuestión tiene indice en 2 campos de texto y 1 númerico
>
> -No tiene claves foraneas
>
>
> Los metodos que se me ocurren son:
> 1.- Usar el metodo de importarlo directo como tabla nueva, drop'ear la
> anterior y renombar la tabla.
> 2.- A la tabla hacer truncate, drop, recrearla e importar los nuevos datos
>
> Respecto al espacio, ¿cómo es mejor para no que vaya creciendo el tamaño en
> disco? en este momento la tabla me mide 1.5GB
> que si borro se recupere el espacio

Creo que lo mejor sería algo así:

begin;
truncate table foo;
copy into foo ...;
commit;

Esto tiene ventajas y desventajas. La desventaja es que truncate
require un lock exclusivo y por lo tanto se bloqueará hasta que todo
otro proceso usando la tabla haya terminado; y además bloqueará todo
otro proceso hasta que el copy haya terminado. La ventaja es que el
COPY inmediatamente después de un truncate en la misma transacción es
optimizado de forma que no necesita meter cada tupla insertada en WAL,
sino que hace un solo fsync al final de la operación, lo cual es más
rápido (esto es negado si tienes wal_level más que "minimal"). La otra
ventaja es que no queda ninguna tupla muerta que limpiar después
mediante vacuum (lo cual podría ser un problema serio).

La otra desventaja es que truncate viola los principios de MVCC (una
transacción muy antigua que haya comenzado antes de esta secuencia, pero
que no haya intentado adquirir un lock en la tabla hasta después que
esta secuencia haya completado, vería una versión inconsistente de esta
tabla).

Nota: el truncate es básicamente lo mismo que drop/create o
create/rename para estos efectos.

Otra cosa: no tiene sentido hacer truncate y después drop.

--
Álvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>