Blair Zajac <[email protected]> writes: > Knut Anders Hatlen wrote: >> Blair Zajac <[email protected]> writes: >> >>> I downloaded d2991-preview-1e.diff and applied it to r737572 of trunk. >>> I don't see the original problem now. Even going to 500 threads and >>> setting derby.locks.waitTimeout to -1 works. >>> >>> Will or when will a patch for d2991 be applied to trunk? >> >> Thanks for testing the patch. A patch for DERBY-2991 will hopefully make >> it into the upcoming Derby 10.5.1 release >> (http://wiki.apache.org/db-derby/DerbyTenFiveOneRelease). Currently, >> we're evaluating the performance impact of the suggested fix. > > Thanks. What kind of performance impact does the patch have on Derby?
The patch makes some index scans copy their position (that is the whole row from the index page) in the middle of the scan. If this happens frequently (for some scans it may happen for every row), you may see a performance drop (up to 10% has been suggested). For most index scans, the copying happens less frequently, and the performance impact is barely observable. And for shorter index scans (those fetching less than 16 rows) it doesn't happen at all, and because of some other changes in the patch, these shorter scans may actually see increased performance with the patch. > To be half joking and half series, without the fix, the performance of > my app goes to 0 when the application runs into this issue. I agree, and I think the performance penalties that have been found till now do not outweigh the benefits of the fix. I will post some more findings on DERBY-2991 shortly, and I think those findings show that more or less all common cases are unaffected by the fix, so I'm currently optimistic that the fix will be included in 10.5.1. -- Knut Anders
