Skip to content

libtracker-data: Optimize easily catchable idempotent deletes

Carlos Garnacho requested to merge wip/carlosg/delete-optimizations into master

From the main commit:

    Operations like "DELETE WHERE { <urn> ... }" can be tiptoed if we know
    that <urn> is not a known resource yet, avoiding it's full evaluation.
    
    These operations are a fairly common result from using TrackerResource
    (e.g. ensuring multivalued properties are in a clean slate), they are
    common enough that it's prominent in first-index tracker-miner-fs-3
    perf records, e.g.:
    
      15.79%     0.01%  pool-tracker-mi  libtracker-sparql-3.0.so.0.100.0  [.] translate_DeleteWhere
    
    With this change in place, the same situation becomes:
    
      3.70%     0.07%  pool-tracker-mi  libtracker-sparql-3.0.so.0.100.0  [.] translate_DeleteWhere

Merge request reports