Re: Creating foreign key on partitioned table is too slow

Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> writes:
> On 2019-Oct-25, Tomas Vondra wrote:
>> The attached patch trivially fixes that by adding a memory context
>> tracking all the temporary data, and then just deletes it as a whole at
>> the end of the function. This significantly reduces the memory usage for
>> me, not sure it's 100% correct.

> FWIW we already had this code (added by commit 2455ab48844c), but it was
> removed by commit d3f48dfae42f. I think we should put it back.

I disagree. The point of d3f48dfae42f is that the management of that
leakage is now being done at the caller level, and I'm quite firmly
against having RelationBuildPartitionDesc duplicate that. If we
don't like the amount of space RelationBuildPartitionDesc is leaking,
we aren't going to like the amount of space that sibling routines
such as RelationBuildTriggers leak, either.

What we ought to be thinking about instead is adjusting the
RECOVER_RELATION_BUILD_MEMORY heuristic in relcache.c. I am not
sure what it ought to look like, but I doubt that "do it all the
time" has suddenly become the right answer, when it wasn't the
right answer for 20-something years.

It's conceivable that "do it if CCA is on, or if the current
table is a partition child table" is a reasonable approach.
But I'm not sure whether we can know the relation relkind
early enough for that :-(

(BTW, a different question one could ask is exactly why
RelationBuildPartitionDesc is so profligate of leaked memory.)

regards, tom lane