I had intended to make varlenas alignment 'c' and have the heaptuple.c force
them to alignment 'i' if they required it. However I've noticed a problem that
makes me think I should do this the other way around.
The problem is that other places in the codebase use the alignment. In
particular arrays do. Also toasting.c expects to get a worst-case size from
att_align rather than a best-case. Also there's indextuple.c but probably I
should get to that in this round anyways.
So now I'm thinking it's best to leave them as alignment 'i' unless
heaptuple.c thinks it can get away without aligning them. This means we don't
have a convenient way for data types to opt out of this header compression.
But the more I think about it the less convinced I am that we need that. The
alignment inside the data type doesn't matter since you'll only be working
with detoasted versions of them unless you specifically go out of your way to
do otherwise.
Once this is done it may be worth having arrays convert to short varlenas as
well. Arrays of short strings hurt pretty badly currently:
postgres=# select pg_column_size(array['a','b','c','d']);pg_column_size
---------------- 56
(1 row)
The only problem with this is if it's more likely for someone to stuff things
in an array and then read them back out without detoasting than it is for
someone to stuff them in a tuple. Probably the risk is the same. There is some
code that assumes it understands how arrays are laid out in execQual.c and
varlena.c.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com
