[ https://issues.apache.org/jira/browse/OAK-8002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Julian Reschke updated OAK-8002: -------------------------------- Description: {{MissingLastRevSeeker}} is slow on DB2. This is because the generic {{MissingLastRevSeeker}} gets candidate in batches (of 100), but in order to do batching, requires results to be sorted by ID. For DB2 we by default have indices on both ID and MODIFIED, but contrary to our expection a query that involves both indices does not perform well. Adding a compound index on ID *and* MODIFIED improves performance, but I'm hesitant to add this just to improve a recovery job. A more logical approach would be not to require batching/sorting by adopting the approach in {{MongoMissingLastRevSeeker}} which doesn't require sorting by ID in the first place. was: {{MissingLastRevSeeker}} is slow on DB2. This is because the generic {{MissingLastRevSeeker}} gets candidate in batches (of 100), but in order to do batching, requires results to be sorted by ID. For DB2 we by default have indices on both ID and MODIFIED, but contrary to our expection a query that involves both indices does not perforn well. Adding a compound index on ID *and* MODIFIED improves performance, but I'm hesitant to add this just to improve a recovery job. A more logical approach would be not to require batching/sorting by adopting the approach in {{MongoMissingLastRevSeeker}} which doesn't require sorting by ID in the first place. > RDBDocumentStore: add RDB-specific MissingLastRevSeeker > -------------------------------------------------------- > > Key: OAK-8002 > URL: https://issues.apache.org/jira/browse/OAK-8002 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk > Reporter: Julian Reschke > Assignee: Julian Reschke > Priority: Minor > Labels: candidate_oak_1_10 > Fix For: 1.12, 1.11.0 > > Attachments: OAK-8002.diff > > > {{MissingLastRevSeeker}} is slow on DB2. This is because the generic > {{MissingLastRevSeeker}} gets candidate in batches (of 100), but in order to > do batching, requires results to be sorted by ID. > For DB2 we by default have indices on both ID and MODIFIED, but contrary to > our expection a query that involves both indices does not perform well. > Adding a compound index on ID *and* MODIFIED improves performance, but I'm > hesitant to add this just to improve a recovery job. > A more logical approach would be not to require batching/sorting by adopting > the approach in {{MongoMissingLastRevSeeker}} which doesn't require sorting > by ID in the first place. -- This message was sent by Atlassian JIRA (v7.6.3#76005)