Packed varlena patch update

I implemented Tom's suggestion of packing the external toast pointers
unaligned and copying them to a local struct to access the fields. This saves
3-6 bytes on every external toast pointer. Presumably this isn't interesting
if you're accessing the toasted values since they would be quite large
anyways, but it could be interesting if you're doing lots of queries that
don't access the toasted values. It does uglify the code a bit but it's all
contained in tuptoaster.c.

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

I think this is the last of the todo suggestions that were mentioned on the
list previously, at least that I recall.

Some implications:

1) There's no longer any macro to determine if an external attribute is
compressed. I could provide a function to do it if we need it but in all
the cases where I see it being used we already needed to extract the fields
of the toast pointer anyways, so it wouldn't make sense.

2) We check if a toasted value is replaced with a new one by memcmp'ing the
entire toast pointer. We used to just compare valueid and relid, so this
means we're now comparing extsize and rawsize as well. I can't see how they
could vary for the same valueid though so I don't think that's actually
changing anything.

Remaining things in the back of my mind though:

. I'm not 100% confident of the GIST changes. I think I may have changed a few
too many lines of code there. It does pass all the contrib regressions
though.

. I think there may be some opportunities for optimizing heaptuple.c. In
particular the places where it uses VARSIZE_ANY where it knows some of the
cases are impossible. It may not make a difference due to branch prediction
though.

. I've left the htonl/ntohl calls in place in the BIG_ENDIAN #if-branch.
They're easy enough to remove and it leaves us the option of removing the
#if entirely and just us use network-byte-order instead of the #ifdef.

I'm a bit worried about modules building against postgres.h without
including the config.h include file. Is that possible? Is it worth worrying
about? I think I could make it fail to build rather than crash randomly.

. One of the regression tests I wrote makes a datum of 1/2Meg. Can all the
build-farm machines handle that? I don't really need anything so large for
the regression but it was the most convenient way to make something which
after compressing was large enough to toast externally. It might be better
to find some less compressible data.

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