When testing commit c6b9204 with CLOBBER_CACHE_ALWAYS, of the 20 hours for
check-world, 001_rep_changes.pl took 1.8 hours. At commit 5406513, the test
failed at a poll_query_until() timeout[1]. The slow part is the logical
replication of "DELETE FROM tab_ins WHERE a > 0", which deletes 100 records
from a table of ~1100 records, using RelationFindReplTupleSeq().
tuples_equal() called lookup_type_cache() for every comparison. Performing
those lookups once per RelationFindReplTupleSeq(), as attached, cut the test's
runtime by an order of magnitude. While performance for CLOBBER_CACHE_ALWAYS
is not important, this is consistent with record_eq() and is easy. I'm
slightly inclined not to back-patch it, though.
[1] This seemed to result from the poll query being 2-3x faster at commit
5406513, not from logical replication being slower. (poll_query_until() times
out after 1800 polls separated by 0.1s sleeps, however long that takes.) I
had guessed that commit 1c7a0b3 greatly accelerated this test case, but it
gave about a 4% improvement under CLOBBER_CACHE_ALWAYS.
