[knot-dns-users] IXFR commit time scaling

Hi Knot team, I'm running Knot as an Auth secondary receiving IXFR from a BIND 9 primary. To isolate bottlenecks I've stripped the config down as far as I know how. Here's what I'm using. zonefile-sync: -1 zonefile-load: none journal-content: none There is no DNSSEC or any downstream IXFR serving happening. Logs are confirming that it is genuine IXFR and no signs of any AXFR fallback. "semantic-checks" is off, and knotd is linked against jemalloc. I'm really trying to make this as quick as possible by avoiding the disk. The pattern: IXFR processing time scales roughly proportionally with total zone size, even when the changeset is small, for example, a few hundred RRs out of several hundred thousand. There is what appears to be a full zone walk on every IXFR commit in the adjust logic, with single threaded execution due to parent befroe child ordering requirements. Although I'd want your confirmation before reading too much into it. Questions: 1. With journal-content: none, does IXFR apply trigger a full in-memory tree walk of the QP-trie, rather than an isolated incremental record-level update? If so, is that a necessary consequence of running without a journal to maintain state? 2. For a secondary with no NSEC/NSEC3, no wildcards or any downstream IXFR'ing, could a "lightweight secondary" mode bypass post-apply bookkeeping that might only be targetted to primaries and signers? 3. Could it rewalk only subtrees where adds or removes happen to their ancestors, rather than the full zone? If NSEC is absent, is the prev pointer chain actually used at query time, or can it be skipped entirely? Our use case is secondary-only, with large zones and high frequency updates. We're hoping there is something on the configuration or roadmap side that might help, and ultimately not sure if we're just bumping up against a realistic constraint. Thanks for the great software btw, loving it. Thanks!