Backport patch to reduce alignment of "name" from int to char.
In the previous coding, if a "name" field in a struct, that was used for direct access to a catalog tuple, i.e. Form_pg_*, was not accidentally aligned to 4-byte boundary, the struct would not match what's stored on disk. I was bit by this, when I tried changing the compresstype field in pg_appendonly from text to name. This seems like a good idea from an upgrade point of view too. This change broke pg_upgrade for any tables that use the name datatype. That's not a big deal, because it shouldn't be used in user tables at all anyway, but might as well take the hit in 5.0 when the upgrade is expected to be more painful anyway. Original commit: commit 5f6f840e Author: Tom Lane <tgl@sss.pgh.pa.us> Date: Tue Jun 24 17:58:27 2008 +0000 Reduce the alignment requirement of type "name" from int to char, and arrange to suppress zero-padding of "name" entries in indexes. The alignment change is unlikely to save any space, but it is really needed anyway to make the world safe for our widespread practice of passing plain old C strings to functions that are declared as taking Name. In the previous coding, the C compiler was entitled to assume that a Name pointer was word-aligned; but we were failing to guarantee that. I think the reason we'd not seen failures is that usually the only thing that gets done with such a pointer is strcmp(), which is hard to optimize in a way that exploits word-alignment. Still, some enterprising compiler guy will probably think of a way eventually, or we might change our code in a way that exposes more-obvious optimization opportunities. The padding change is accomplished in one-liner fashion by declaring the "name" index opclasses to use storage type "cstring" in pg_opclass.h. Normally btree and hash don't allow a nondefault storage type, because they don't have any provisions for converting the input datum to another type. However, because name and cstring are effectively the same thing except for padding, no conversion is needed --- we only need index_form_tuple() to treat the datum as being cstring not name, and this is sufficient. This seems to make for about a one-third reduction in the typical sizes of system catalog indexes that involve "name" columns, of which we have many. These two changes are only weakly related, but the alignment change makes me feel safer that the padding change won't introduce problems, so I'm committing them together.
Showing
想要评论请 注册 或 登录