"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Mon, 2007-12-17 at 08:47 -0500, Andrew Dunstan wrote: > >> This strikes me as such a corner case that it's likely not to be worth it. >> >> If you really want to save space along these lines, one better place to >> start might be mutable with column ordering - see >> http://archives.postgresql.org/pgsql-hackers/2006-12/msg00983.php . That >> would mean that we would be able to move nullable columns physically to >> the tail which in turn might help this suggestion have more effect.
That would only be one factor in deciding how to arrange columns but you have to decide what order to store them when you're creating the table. You can't move them around tuple by tuple. Only when rewriting the whole table would you be able to move them around. My first thought on how to arrange the columns would be: fixed-size not nullable fixed-size nullable all variable-sized With this additional tweak you would want to change that to: fixed-size not nullable fixed-size nullable variable-size not nullable variable-size nullable I don't think you would want to store variable-sized not nullable columns before fixed-sized nullable columns because in the cases where they're not null you want to be able to use the cached offsets. There could be some other factors to the decision when it comes to alignment though. It might be worth putting a nullable column before a not null column if it lets you fix the alignment and it's rarely actually null. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's PostGIS support! ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings