Re: Composite type storage overhead
От | Thomas Kellerer |
---|---|
Тема | Re: Composite type storage overhead |
Дата | |
Msg-id | 2d715b05-dce4-9aec-e01b-cb3213386f5c@gmx.net обсуждение исходный текст |
Ответ на | Re: Composite type storage overhead (Laiszner Tamás <t.laiszner@outlook.com>) |
Ответы |
Re: Composite type storage overhead
|
Список | pgsql-general |
> 3. The value is logically defined as a 128-bit integer, that is in > itself a compound value split into a few "bit groups". Extracting > these parts can be done by simple (and supposedly efficient) bitwise > operators when stored as integer, but becomes much more cumbersome > with UUID, I guess. This is usually a bad idea. Putting logic into the primary key value and merging different types of information in a single column is typically not sucha good idea. (And it violates first normal form to begin with) I would strongly recommend to revisit this idea, and e.g. think about a multi-column primary key instead. Where each of these"groups" are stored in a separate column where the actual (business) value can be retrieved without any bitshiftingor similar operations. Thomas
В списке pgsql-general по дате отправления: