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 <alvhe...@alvh.no-ip.org> - Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda@postgresql.org) Para cambiar tu suscripci�n: http://www.postgresql.org/mailpref/pgsql-es-ayuda
