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 ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
