Re: postgres_fdw batching vs. (re)creating the tuple slots

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2021-05-30 22:22:10 +0200, Tomas Vondra wrote:
>> The other problem is that ResourceArrayAdd/Remove seem to behave a bit
>> poorly with very many elements - I'm not sure if it's O(N^2) or worse,
>> but growing the array and linear searches seem to be a bit expensive.

> Hm. I assume this is using the hashed representation of a resowner array
> most of the time, not the array one? I suspect the problem is that
> pretty quickly the ResourceArrayRemove() degrades to a linear search,
> because all of the resowner entries are the same, so the hashing doesn't
> help us at all. The peril of a simplistic open-coded hash table :(

Not only does ResourceArrayRemove degrade, but so does ResourceArrayAdd.

> I think in this specific situation the easiest workaround is to use a
> copy of the tuple desc, instead of the one in the relcache - the copy
> won't be refcounted.

Probably. There's no obvious reason why these transient slots need
a long-lived tupdesc. But it does seem like the hashing scheme somebody
added to resowners is a bit too simplistic. It ought to be able to
cope with lots of refs to the same object, or at least not be extra-awful
for that case.

regards, tom lane