On Thu, Oct 28, 2010 at 12:23 PM, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
> On Thu, Oct 28, 2010 at 10:09 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
>> Bert and Erik and Philip and I discussed on IRC today the merits, or
>> lack of merits, of allowing repos-id/repos-relpath to be elided in the
>> NODES table BASE layer (op_depth = 0).
>>
>> * The data is not currently elided.
>>
>> * Some queries for locks currently assume the data is not elided.
>>
>> * Elision could save a bit of DB size, which *might* contribute to a
>> little bit of general DB performance.
>>
>> * The option of elision results in the need for all users of this data
>> to call svn_wc__db_scan_base_repos() or the internal version
>> scan_upwards_for_repos(), which is an extra maintenance burden and extra
>> run-time cost.
>>
>> We concluded it would be better to require the columns to be always
>> filled in. I'll do this soon if no objections.
>
> As I understand it, our original intention for elision was to make
> switch and relocate go much faster, since only one row would be
> updated instead of the entire tree. If that creates too much of a
> burden elsewhere, then yes, we can probably nuke it (and we can
> probably write a good enough query to make the relatively uncommon
> operations of switch and relocate only negligibly slower).
>
> This is one use case, however, and isn't necessarily the only one.
At the same time, with code written to properly leverage SQL this is
the sort of scenario that we should not worry about anymore. SQLite
ought to be able to update all the rows in the DB faster than our old
code could walk the tree and open all the entries files, let alone
rewrite them.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2010-10-28 18:29:51 CEST