Nick Burrett <nick@dsvr.net> writes:
> I expected that specifying a specific length for a column would allow
> for more efficient indexing and searching because:
> a) you already know the exact length of the column
> b) potentially the column-data could be stored starting on a word-boundary
> c) apply string comparison functions that are optimised for data
> starting on word-boundaries (i.e. by comparing words rather than bytes).
> Certainly for the C-locale.
None of those considerations really apply for Postgres. We used to have
some (very marginal anyway) optimizations that assumed CHAR(n) is
fixed-width, but they went away when we added support for multibyte
character encodings. In any case there isn't anything here that
wouldn't be swamped by increased I/O demands due to the wasted space.
Maybe if all your machine names run between 29 and 32 characters it'd
be worth doing, but if you're paying any actual space cost to padding
I think it has to be a net loss.
regards, tom lane