Re: [pgsql-es-ayuda] Tamaño

Alvaro, muchas gracias por la información.
No sabia q el tipo numeric era mas lento que los otros tipos.
Abusando de tu colaboración te pregunto para aclarar mas: volví a revisar la
documentación acerca de los tipos numéricos, los INT2, INT4, INT8 dicen
"fixed precision". Los FLOAT4 y FLOAT8 dicen "variable precision", y NUMERIC
y DECIMAL dicen "user specified precision". Lo de fixed precision significa
que si almaceno 45.14, en la BD queda como decimal los .14 y no
aproximaciones como 45.1399999999??
¿Qué tipo usarias si tienes q almacenar un numero de documento q no lleva
decimales, por ej 1.890.478.477 ?
¿Que tipo usarias si debes almacenar precios, por ej $ 145.789.547,48 ?
¿En que casos usarias float, decimal y numeric?

Muchas gracias Alvaro

Cordial saludo
Juan Carlos Villalobos C

"Los hábitos son el mejor de los sirvientes o el peor de los amos"
Nathaniel Emmons

----- Original Message -----
From: "Alvaro Herrera" <alvherre(at)alvh(dot)no-ip(dot)org>
To: "JucaviLst" <jucavilst(at)elicubs(dot)com>
Cc: <pgsql-es-ayuda(at)postgresql(dot)org>
Sent: Tuesday, October 04, 2005 10:09 AM
Subject: Re: [pgsql-es-ayuda] Tamaño

On Tue, Oct 04, 2005 at 08:35:44AM -0500, JucaviLst wrote:
> Saludos listeros, soy nuevo en postgres. Tengo una duda, como puedo
calcular
> el tamaño de crecimiento en bytes o megas de una tabla por ejemplo para
> 1.000.000 de registros. La tabla es la sgte
>
> CREATE TABLE lecturas
> (
> id numeric(12, 0) DEFAULT 0 PRIMARY KEY,
> sensor numeric(4, 0) DEFAULT 0,
> valorlectura numeric(10, 3) DEFAULT 0,
> fecha date,
> hora char(8),
> valordia numeric(5, 0) DEFAULT 0,
> respuesta numeric(1, 0) DEFAULT 0
> )

NUMERIC usa 4+n bytes, donde n depende del tamaño del numero que
almacenes. Para el almacenamiento se usa base 10000, donde cada digito
es un int32 (o sea 4 bytes), por lo tanto para almacenar numeros chicos
de poca precision usara 8 bytes, creciendo de a 4 bytes (8, 12, 16, ...)

La fecha me parece que usa 4 bytes. El char(8) usa minimo 5 bytes,
maximo 4+8 = 12 bytes.

Por lo tanto en esa tabla tendras que los registros mas chicos serian de
5*8 + 5 + 4 = 49 bytes. Los mas grandes serian de 80 bytes. Todo esto
asume que no tienes ningun NULL. Puedo equivocarme en las cantidades
pero es mas o menos por ahi la cosa. A eso agregale 24 o 28 bytes de
overhead por tupla, para un total minimo de 73 bytes. Si tienes algun
NULL, agrega 4 bytes extras y quita los bytes que corresponden a esa
columna.

Si reemplazaras todos los NUMERIC(n,m) por INTEGER, el espacio de cada
uno serian 4 bytes fijos, y ademas la tabla funcionaria mucho mas
rapido. (En otras palabras, no uses NUMERIC si no es absolutamente
indispensable, porque es lento). Si el acceso a esta tabla es punto
critico de rendimiento, ajusta el orden para que haya mejor
alineamiento y cache de offsets:

create table
lecturas (
id integer primary key,
sensor integer not null,
fecha date not null,
valordia int2 not null
respuesta int2 not null,
hora time not null,
valorlectura numeric(10, 3) not null
)

--
Alvaro Herrera
http://www.PlanetPostgreSQL.org
"In a specialized industrial society, it would be a disaster
to have kids running around loose." (Paul Graham)