On Thu, Oct 28, 2010 at 11:29 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> 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.
Correct. And we still have to do the update crawl on a switch or relocate, no?
-Hyrum
Received on 2010-10-28 18:38:19 CEST