-----Mensaje original----- De: Alvaro Herrera [mailto:alvhe...@alvh.no-ip.org] Enviado el: miércoles, 03 de junio de 2009 18:22
> Creo que estás exagerando :-) Wehehe el mensaje lo escribí ayer en la última hora de curro y ya estaba cansadillo ^^ > Como ya dijeron, basta que te crees un > trabajo en Cron que se ejecute una vez al mes y cree la tabla del mes > siguiente. Esto lo veo claro, también lo de hacerlo a mitad de mes y demás. > No sé a qué trigger te refieres. Respecto a Slony, es obvio que es un > poco más de trabajo, y tienes que tener cuidado con las DDL, pero no > tendría por qué ser nada del otro mundo ... Me refería al trigger para la tabla principal, que mande los datos a donde corresponda. Hoy más despierto veo que el nombre se puede generar automáticamente a partir de la fecha así que no es problema. Con Slony, el problema lo veo en actualizar los conjuntos de replicación con las nuevas tablas, que no se me ocurre una manera de hacerlo automático (crear el nuevo conjunto, fusionarlo con el otro). Lo hice con pgadmin3 y no se aún cómo hacerlo con código SQL, lo miraré. > (En todo caso esto ilustra por qué yo no soy muy fanático de recomendar > particionamiento a menos que sea absolutamente necesario, al menos en > las versiones actuales de Postgres. Quizás en el futuro se mejore y sea > todo mucho más sencillo). La razón por la que me lo planteo es que habrá muchísimos datos, del orden de decenas de millones, y se consultarán casi siempre por fecha. ¿Qué otras opciones tengo para acelerar esto? Tengo entendido que el tiempo de consulta es directamente proporcional al tamaño de tabla, por eso pensé en partir lo primero... Jorge -- TIP 1: para suscribirte y desuscribirte, visita http://archives.postgresql.org/pgsql-es-ayuda
