Horton

Thread

Commits

  1. Optimize RelationFindReplTupleSeq() for CLOBBER_CACHE_ALWAYS.

  2. Skip WAL for new relfilenodes, under wal_level=minimal.

  3. Add missing break out seqscan loop in logical replication

  4. In pgwin32_open, loop after ERROR_ACCESS_DENIED only if we can't stat.

  1. Optimizing RelationFindReplTupleSeq() for CLOBBER_CACHE_ALWAYS

    Noah Misch <noah@leadboat.com> — 2020-04-06T08:54:20Z

    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.