Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Diseño para una BD con muchos registros...

From: Andrés P(dot)P(dot) <solopostgres(at)gmail(dot)com>
To: pgsql-es-ayuda(at)postgresql(dot)org
Subject: Re: [pgsql-es-ayuda] Re: [pgsql-es-ayuda] Diseño para una BD con muchos registros...
Date: 2010-05-07 17:08:51
Message-ID: s2l8a9759491005071008l493f35a8sed681af5ff53694a@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

yap.. mis comentarios..

> No, para nada. Tú haces una consulta sobre tabla_todos_meses con un WHERE
> fecha=...
> y automáticamente postgres se encarga de usar sólo las tablas de esos
> meses.
> (Lee sobre el parámetro constraint_exclusion en la documentación)
>
> Por otra parte, considera que si el número de teléfono es una constante,
> esa
> consulta usará un índice en cada tabla para buscar sólo los registros de
> ese
> teléfono, y por lo tanto no tiene que recorrer los 600 millones de
> registros en
> cada tabla.
>
> Otra cosa que te puede interesar es este módulo para manejar prefijos; lo
> escribió Dimitri Fontaine precisamente para manejar datos telefónicos.
> http://prefix.projects.postgresql.org/

Ahh.. ok.. en realidad fui inconsistente al pensar que tu propuesta de
modelo particionado lo podía "simular" separando tablas...y derivar la data
a una tabla especifica según la fecha del COPY.. pero por lo visto me
volé..............Ok!...... osea, debo ponerme a leer los links de herencias
y particionamiento...y evaluar el módulo que me indicas..

> Hoy en día no tiene sentido poner una base de datos de un tamaño "grande"
> en un servidor que no sea de 64 bits. Me imagino que mínimo estarás
> pensando
> en usar unos 16 GB de memoria, cierto?
>

En desarrollo sólo cuento con máquinas de 64bits, pero con S.O. de 32bits.
y 8GB en RAM... asi que tendré que probar ahí y extrapolar
proporcionalmente las estimaciones a un S.O. de 64 y 16 en RAM??...(sin
mencionar si el factor CPU tiene alguna gran incidencia..1,2,3....x core...)

> Sobre si es mejor dejar el índice o reconstruirlo durante la carga masivo,
> es algo que deberías medir. Creo que en algunos casos puede ser mejor
> borrarlos y en otros dejarlos.

Si es algo que te complica mucho, quizás podrías hacer tablas por semanas
> en lugar de tablas por meses.

Sip... las mediciones serán el mejor parámetro para tomar esa decisión..

Gracias nuevamente... si tienes algún link de ejemplos de particionamiento
para irlo contrastando con la doc... se agradece.

Saludos
AP.

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Vladimir Urquia Cordero 2010-05-07 18:37:46 Ayuda sobre vistas materializadas!!
Previous Message Jaime Casanova 2010-05-07 16:45:03 Re: Ayuda sobre vistas materializadas!!