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
pathsmay be annoying to maintain. The flip side is it would make it easier to read varlena headers in gdb which I
foundkind 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
hidethat all in the att_align and att_addlength macros but a) it would never be possible to hide most of it and b) it
wouldrequire 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
attributesthat 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_datumand 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?
Themacro api is not quite complete enough for this yet so it may make sense to tackle at least one code site before
mergingit 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
