Packed short varlenas, what next?

I'm really curious to know how people feel about the varlena patch. In
particular I know these issues may elicit comment:

1) Do we really need a special case for little-endian machines? I think it
would be trivial to add but having two code paths may be annoying to
maintain. The flip side is it would make it easier to read varlena headers
in gdb which I found kind of annoying with them in network byte order.

2) How do people feel about the way I inlined most of the VARATT_IS_SHORT
cases in heaptuple.c. I tried at first to hide that all in the att_align
and att_addlength macros but a) it would never be possible to hide most of
it and b) it would require a few more redundant tests.

3) How do people feel about not allowing an escape hatch for new types and
explicitly exempting int2vector and oidvector. The alternatives are either
a) adding a new column to pg_type and pg_attribute and setting that on
catalog attributes that are accessed through GETSTRUCT (as the first
varlena in the table) and also setting it on oidvector and int2vector
because they don't call pg_detoast_datum(). Or b) fixing int2vector and
oidvector to pass through pg_detoast_datum and fix all the accesses to the
first int2vector/oidvector in every catalog table to use fastgetattr
instead. or c) keep things as they are now.

4) Should I start hitting the more heavily trod codepaths in text.c and
numeric.c to avoid detoasting short varlenas? The macro api is not quite
complete enough for this yet so it may make sense to tackle at least one
code site before merging it to be sure we have a workable api for data
types that want to avoid unnecessary detoasting.

The latest patch is at

http://community.enterprisedb.com/varlena/patch-varvarlena-12.patch.gz

I've been doing some benchmarking, I see a 9.7% space saving on the
Benchmark-SQL 5.2 schema which translates into about a 8% performance gain.
The DBT2 benchmarks show a smaller 5.3% space saving because we had already
done a lot more optimizing of the schema.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com