[
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 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.
was:
MissingLastRevSeeker 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
> Fix For: 1.12
>
> 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 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.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
