Updated patch:
I went through the "high traffic" areas and levelled them up to using the new
macros to avoid "detoasting" smaller arguments. They key areas are really
btree operators since they have a noticeable effect on sorts, especially index
builds, when the data being sorted fits in memory.
There is a bit of a name-game here. The macros I made are called
VARDATA_ANY(datum) VARSIZE_ANY(datum) AND VARSIZE_ANY_EXHDR(datum).
And the datatype macros are, for example, PG_GETARG_TEXT_PP() and
DatumGetTextPP() -- short for "packed pointer".
Maybe not the prettiest names in the world but clear and I've found them
pretty easy to spot when I'm looking for inconsistent use of
VARSIZE_ANY<->VARDATA for example. I thought of PVARSIZE/PVARDATA (for
"packed") but I'm afraid it would camouflage such cases.
Anyone have any better ideas? If not I'm satisfied with them...
Except maybe VARSIZE_ANY_EXHDR() which seems too long.
I got to almost everything in varlena.c and varchar.c so that includes text,
bpchar, and bytea as well as varchar's few procedures. That includes probably
more than I really needed to, but as long as the datatypes are working with
bytes it's convenient enough.
Also, I replaced my tweaks to hstore and pg_trgm with Teodore's.
And of course updated CVS.
http://community.enterprisedb.com/varlena/varvarlena-20.patch.gz
I'm going to be putting this aside for a little while. I think it's really
done. There's more that can be done of course, hit inet and numeric with the
new macros, for instance. But I want to see what happens when it gets reviewed
before I do that kind of bookkeeping.
One thing that I've left in there again is the htonl/ntohl macros in the
big-endian case. It really makes sense to either remove them or remove the
#ifdef.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
