Re: Tabla inserta constantemente registros

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Alejandro Carrillo <fasterzip(at)yahoo(dot)es>
Cc: Ayuda <pgsql-es-ayuda(at)postgresql(dot)org>, "jaime(at)2ndquadrant(dot)com" <jaime(at)2ndquadrant(dot)com>
Subject: Re: Tabla inserta constantemente registros
Date: 2012-02-13 16:38:10
Message-ID: 1329150559-sup-5335@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda


Excerpts from Alejandro Carrillo's message of vie feb 10 18:35:40 -0300 2012:
> Buenas tardes,
>
> Tengo un sistema que inserta cada minuto 200 registros, en una tabla (usando una function), y la tabla puede ser consultada en cualquier momento a través de otra function. Es decir, al año puede tener la tabla 103 680 000 registros, los cuales pueden ser consultados en cualquier momento. Los datos no se actualizan. ¿Que se recomienda para que las inserciones y las consultas a través de estas 2 functions sean rápidas y no afecten el rendimiento de la BD?

Hmm, nada.

El particionamiento ayuda con asuntos administrativos. Por ejemplo,
para borrar datos antiguos es más fácil borrar la partición antigua que
hacer un DELETE sobre una tabla grande y después vacuum. Hacer un
respaldo de varias tablas menores puede ser más conveniente que una sola
muy grande.

Hay algunos tipos de consultas que funcionan mejor sobre un esquema
particionado que sobre una sola tabla grande, sobre todo si involucran
búsquedas por rangos grandes de la llave de particionamiento; esto te
permite hacer seqscan sobre la partición o particiones involucradas en
vez de hacer un seqscan sobre toda la tabla. Y otras cosas de ese
estilo. Pero una búsqueda común haciendo igualdad o un rango pequeño
sobre un campo indexado, funciona casi igual sobre una partición que
sobre una sola tabla grande. (Digo casi igual porque en el esquema
particionado es levemente más lento, aunque normalmente no es tanto como
para representar un problema).

Pero Postgres no tiene buen soporte para particionamiento actualmente.
Particionar es engorroso y feo, y es fácil hacer varias cosas mal,
creándote más problemas de los que te soluciona. Si puedes evitarlo,
tanto mejor. No deberías considerar que el particionamiento es una bala
de plata, ni mucho menos que es simple cargarla en una pistola existente
para disparar.

Una cosa que solía ser importante pero ya no lo es tanto es el tema de
vacuum. Antes cada vacuum debía recorrer la tabla completa para limpiar
tuplas muertas. Ya no es así; cada vacuum sólo necesita recorrer
aquellas páginas que efectivamente tienen tuplas muertas. El resto se
las salta. Sólo es necesario hacer un recorrido completo de la tabla
una vez cada 200 millones de transacciones; y las transacciones de sólo
lectura no cuentan. O sea en tu caso cada casi dos años (obviamente
menos si hay más cosas operando en la BD que sólo inserciones desde los
GPSs).

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

In response to

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Alvaro Herrera 2012-02-13 16:50:22 Re: Problema al restaurar una BD
Previous Message Mario Rodriguez 2012-02-13 15:10:26 Re: Problema al restaurar una BD