I was just doing some profiling of plpgsql record operations, and
noticed that an unreasonable amount of runtime was being consumed
by palloc/pfree calls coming from CreateTupleDescCopy. The reason
for this of course is that each attribute's storage is separately
palloc'd. This seems a little silly given that the tupdesc
management code doesn't have any provision for changing the number
of attributes in an existing tupdesc. We could just as well
allocate all the space needed in one palloc call, with a little bit
of added address-arithmetic to set up the pointers. This would
require some localized changes in tupdesc.c and relcache.c,
but most users of tupdescs would never know the difference.
Can anyone see a reason not to make this change?
regards, tom lane