On 08/10/2013 10:28 AM, Christian Boos wrote: > Hello Eli! > > On 8/10/2013 4:54 AM, Eli Carter wrote: ... >> 3. Address half of the root problem by making the >> CachedRepository.previous_rev() call self.repo.previous_rev() >> unconditionally and not use the database cache. The database solution >> will take time based on the size of the node_change table, but the >> repository already has links to parent revs and can find the information >> much more directly. In the case I was testing, the previous_rev() call >> was taking over 200 seconds, and with the patch now takes under a >> second. (part of db-locked-mitigation-part3.patch) > > Ok, that seems to help. The "real" solution would be to find a > appropriate way to index that table and optimize that query. I tried a > few things so far, but without success as simply adding an index on the > repo/path won't help as SQLite won't use it with that query (EXPLAIN > QUERY PLAN is helpful here).
Ok, so I think we have a reasonable fix for the 'previous_rev' issue, but next_rev is still problematic. So my next idea involves a database schema change: add a 'previous_rev' column to the node_change table. During the repo.sync(), we'd have to calculate the previous_rev for that particular node, and for each of its parents (which implies entries I don't think we have currently, and may require some new 'change_type' meaning "a child node changed"). Given that, we should be able to do SELECT rev FROM node_change WHERE path = <our path> AND previous_rev = <our rev>. An index on those should then provide an additional performance boost, I think. Ignoring for the moment that it requires a schema change, does that sound like something that would do what we want? Looks like the previous_rev call crosses copies; I *think* that's the behavior we want for this use case, but I haven't convinced myself of that completely yet. I need to figure out if base_rev/base_path will have the information needed when there are copies... But... even if that solves the problem, it implies a db change. And I want to find something acceptable for 0.12-stable. (The way trac/env.py treats db version numbers doesn't really allow for database upgrades within a release line without bringing in all database changes from trunk. There are approaches that would allow for it, but... that's a lot of heavy lifting I don't want to tackle right now.) Thinking aloud, Eli -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-dev. For more options, visit https://groups.google.com/groups/opt_out.
