Re: excepcion en SELECT *

From: Juan Manuel Acuña Barrera <gps1mx(at)gmail(dot)com>
To: Lista PostgreSQL en Español <pgsql-es-ayuda(at)postgresql(dot)org>
Subject: Re: excepcion en SELECT *
Date: 2011-05-10 16:37:35
Message-ID: 7DA0A652-E9EF-491D-9BBD-A1EDAC5C75CC@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-es-ayuda

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

El 10/05/2011, a las 10:58, Jaime Casanova escribió:

> 2011/5/10 Juan Manuel Acuña Barrera <gps1mx(at)gmail(dot)com>:
>> El 10/05/2011, a las 10:25, Álvaro Hernández Tortosa escribió:
>>
>>> Tue, May 10, 2011 at 10:07:46AM -0500, Juan Manuel Acuña Barrera escribió:
>>>
>>>>> Estoy de acuerdo, suele ser muestra de diseño no normalizado
>>>>> (aunque tener muchas columnas no es condición suficiente de diseño no
>>>>> normalizado, claro) y, dependiendo de algunos factores, puede llevar a
>>>>> un menor rendimiento.
>>>>
>>>> Para tenerlo como referencia, cuantas son _muchas_ columnas en postgresql? 50? 100? 500?
>>>
>>> Bueno... no creo que haya un número que lo determine. Se trata
>>> de que esté normalizado, no de que tenga pocas columnas. Así que depende
>>> mucho de los datos que se están modelizando. No me atrevería a dar una
>>> cifra... pero como referencia el límite de columnas en una tabla en
>>> postgresql oscila entre 250 y 1600, dependiendo de los tipos de datos
>>> usados... y para mí estos deberían ser límites que nunca se alcanzaran
>>> en casos normales...
>>
>> Bien, me quedo mucho más tranquilo, creo que la tabla más grande que tengo es de como unas 80 columnas, y ya sentía que eran muchas.
>>
>
> Veamos... asumamos que todas esas 80 columnas son tipo integer por lo
> que usarian 4bytes c/u. El tamaño de la fila promedio en esa tabla
> (asumiendo que no hay nulos) seria: (80*4)+(una cabecera que me parece
> es de 24 bytes) = 344 bytes por registro

Bueno, de 80 columnas, unos 75 son integer, sin nulos.

>
> Lo que significa que en una pagina de disco de 8kb almacenaras hasta:
> 23 registros por pagina.
>
> Si es una tabla mediana, digamos 1millon de registros, y quieres
> obtener el 10% de la tabla en un select (esto serian 100000 registros)
> tendrias que leer al menos: 4348 paginas de disco (y esto asumiendo
> que los registros estan grabados de forma secuencial y que no tienes
> tuplas muertas)

Tengo como unos 500,000 o 600,000 registros.

>
> Esto que significa? depende... depende de la velocidad de tu disco,
> depende de cuantas paginas de disco lee el SO en cada operacion de
> entrada/salida, etc.
>
> Ahora, considera la situacion en tu caso en que no todos los campos
> son enteros (algunos seran timestamp, 8 bytes; algunos seran de
> longitud variable, etc). Tambien considera el tamaño de la tabla
> (numero de registros) y el uso de la misma, por ejemplo una tabla de
> parametros no se usa mucho asi que no importara mucho pero una tabla
> que con una cantidad considerable de registros y que se consulte con
> mucha frecuencia no me gustaria que tenga 80 columnas... claro que ese
> es mi criterio personal...

No es una tabla que se use mucho, de hecho se usa un par de veces al mes, durante los procedimientos nocturnos de cierre de cuentas. Todo el proceso dura unas horas, pero es sin usuarios conectados, y es el único proceso que se corre, una vez que termina arroja los resultados de las operaciones a otra tabla que tiene aproximadamente unos 500 registros, y en esa es en realidad donde trabajan los clientes.

Independientemente de los "atenuantes" que menciono, coincido completamente contigo que es una tabla grande, yo en general prefiero las tablas mucho más pequeñas, aunque nunca había hecho las cuentas de esa manera tan clara como lo haz presentado tu.

Como les había comentado en un correo anterior, he trabajado mucho tiempo con mysql, pero apenas soy un novato en postgresql, y de hecho quiero migrar varias aplicaciones a postgresql, entre ellas justamente la que se menciona que tiene una tabla con 80 columnas. Espero poder aprovechar este momento de migración para rediseñar esa tabla y dividirla en varias tablas más pequeñas.

Saludos!

Juan Manuel.

>
> --
> Jaime Casanova www.2ndQuadrant.com
> Professional PostgreSQL: Soporte y capacitación de PostgreSQL

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)

iEYEARECAAYFAk3JadIACgkQTc4QiYN6hDcANwCfZ42yt4GhBtEi1Kx3NAdpzB6e
SiMAnRmgLQvl62Lh0pbun4qxF8TP05ab
=JyCB
-----END PGP SIGNATURE-----

In response to

Responses

Browse pgsql-es-ayuda by date

  From Date Subject
Next Message Marcelo Robin 2011-05-10 16:45:16 INVALID BYTE SEQUENCE FOR ENCONDING UNICODE
Previous Message @Salmuz 2011-05-10 16:36:15 Versión del Postgresql mas estable