#1 has been found by other customer, and already fixed by .
#2 is due to a query we invoke at the beginning of replicating,
Replicator::findExistingConflicts() calling unresolvedDocsEnumerator(). For database as large as 3GB, as the PR told, it could take several minutes. The author tried SQLite's "INDEXED BY" clause to have boosted the performance to "almost instantly." However, In SQLite's document, it is suggested that, "the INDEXED BY clause is _not intended for use in tuning the performance of a query."
pointed out that the query should not use ORDER BY. My reading of the code also shows it shouldn't use it in the Lithium. However, also as pointed out, in Helium, because of BothKeyStores, we will do sort. (ORDER BY key causes SQLite not use the index of conflicts flag).
This ticket is to explore if we can get SQLite to use the index. "Several minutes" is quite long before replicator starts the messaging.
Build couchbase-lite-c-3.2.0-29 contains couchbase-lite-core commit d37f350 with commit message: : Replicator starts up slow for big database (#1859)
CB robot September 12, 2023 at 2:19 PM
Build couchbase-lite-ios-3.2.0-40 contains couchbase-lite-core commit d37f350 with commit message: : Replicator starts up slow for big database (#1859)
CB robot September 6, 2023 at 12:31 AM
Build couchbase-lite-log-3.2.0-15 contains couchbase-lite-core commit d37f350 with commit message: : Replicator starts up slow for big database (#1859)
CB robot September 5, 2023 at 9:14 PM
Build couchbase-lite-cblite-3.2.0-15 contains couchbase-lite-core commit d37f350 with commit message: : Replicator starts up slow for big database (#1859)
CB robot August 8, 2023 at 6:15 PM
Build couchbase-lite-core-3.2.0-86 contains couchbase-lite-core commit d37f350 with commit message: : Replicator starts up slow for big database (#1859)
Fixed
Pinned fields
Click on the next to a field label to start pinning.
This is to follow up with an external PR, https://github.com/couchbase/couchbase-lite-core/pull/1415.
This PR intends to addresses two performance bottle-necks,
{{speedup nextExpiration query }}
[speedup unresolvedDocsEnumerator|https://github.com/couchbase/couchbase-lite-core/pull/1415/commits/212630af2010fce2a03240df5622fe3b0d0a92bf]#1 has been found by other customer, and already fixed by .
#2 is due to a query we invoke at the beginning of replicating,
Replicator::findExistingConflicts() calling unresolvedDocsEnumerator(). For database as large as 3GB, as the PR told, it could take several minutes. The author tried SQLite's "INDEXED BY" clause to have boosted the performance to "almost instantly." However, In SQLite's document, it is suggested that, "the INDEXED BY clause is _not intended for use in tuning the performance of a query."
pointed out that the query should not use ORDER BY. My reading of the code also shows it shouldn't use it in the Lithium. However, also as pointed out, in Helium, because of BothKeyStores, we will do sort. (ORDER BY key causes SQLite not use the index of conflicts flag).
This ticket is to explore if we can get SQLite to use the index. "Several minutes" is quite long before replicator starts the messaging.