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 ---------------------------(end of broadcast)--------------------------- TIP 3: 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