From: | Francisco Olarte <folarte(at)peoplecall(dot)com> |
---|---|
To: | Edwin De La Cruz <edwinspire(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Lista Postgres ES <pgsql-es-ayuda(at)postgresql(dot)org> |
Subject: | Re: Tamaño de Campo UUID |
Date: | 2018-04-27 08:21:20 |
Message-ID: | CA+bJJbzALCzKeusqS+md0WzdmxhAxnZMO1yWGqqMMV0w7eZB6A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-es-ayuda |
Edwin:
2018-04-26 21:39 GMT+02:00 Edwin De La Cruz <edwinspire(at)gmail(dot)com>:
....
> Se me hizo que en algún lugar leí que había unos tipos de datos que
> reservaban una cantidad de bits fijo, haya o no datos.
Parcialmente correcto si recuerdo bien. Me parece que Pg usa un
BITMAP para marcar que campos son nulos DE LOS QUE PUEDEN SER NULOS.
Para los NOT NULL se ahorra el bit, y reserva el espacio, pero en ese
caso no puede "no haber datos". Si son campos de tamaño fijo es
posible que reserve un espacio fijo.
Si te defiendes con el Ingles, prueba a leer alrededor de esto:
https://www.postgresql.org/docs/10/static/storage-page-layout.html#HEAPTUPLEHEADERDATA-TABLE
En resumen, para lo que querias incialmente.
Si el campo es NULL - 1 bit de 'is-null' mas lo que ocupe el dato, que
sera constante o variable, si esta presente. Como el bit SIEMPRE
viene, ahorras espacio con los NULL.
Si el campo es NOT NULL - lo que ocupe, Pg no pone el bit.
Francisco Olarte.
From | Date | Subject | |
---|---|---|---|
Next Message | Guillermo E. Villanueva | 2018-04-27 14:30:49 | BDR |
Previous Message | Edwin De La Cruz | 2018-04-26 19:39:04 | Re: Tamaño de Campo UUID |