1. 24 Nov, 2020 5 commits
  2. 23 Nov, 2020 2 commits
  3. 12 Nov, 2020 4 commits
  4. 09 Nov, 2020 2 commits
  5. 07 Nov, 2020 2 commits
    • Carlos Garnacho's avatar
      libtracker-data: Fix code typo · 7eff406e
      Carlos Garnacho authored
      This was rightfully issuing a compiler warning. Fix the offset being in/out.
    • Carlos Garnacho's avatar
      libtracker-data: Optimize easily catchable idempotent deletes · 4677d810
      Carlos Garnacho authored
      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
  6. 05 Nov, 2020 2 commits
  7. 04 Nov, 2020 3 commits
  8. 02 Nov, 2020 1 commit
    • Sam Thursfield's avatar
      README.md: List project goals · 0ca04fb8
      Sam Thursfield authored
      Make these explicit to make future design discussions easier.
      Goals can of course be changed in future as the project evolves.
  9. 31 Oct, 2020 2 commits
  10. 20 Oct, 2020 5 commits
  11. 18 Oct, 2020 3 commits
    • Sam Thursfield's avatar
      Merge branch 'wip/carlosg/parallel-stmts' into 'master' · e181a354
      Sam Thursfield authored
      Improve behavior on parallel queries
      See merge request !333
    • Carlos Garnacho's avatar
      libtracker-data: Favor free interfaces over new ones harder · 2d9743a9
      Carlos Garnacho authored
      We typically do that, but once we've found that the first interface
      in the pool is already busy with other statements, we assume they're
      all busy and jump into creating a new interface. Even worse, if that
      interface is kept busy indefinitely, every new query will opt for
      creating a new interface, quickly filling the allotment.
      There might be other interfaces in the pool that are already
      free, so check all of them before trying to create a new interface.
      This makes us more conservative at creating new interfaces on load
      periods, only doing so if all interfaces are actually busy.
    • Carlos Garnacho's avatar
      libtracker-sparql: Batch TrackerNotifier queries · 1412da10
      Carlos Garnacho authored
      If we happen to get a high enough amount of updates, batched changes
      accumulate, all querying for the additional information. This
      accumulation of the same query leads at best to compiling new
      statements (as the cached one is already in use). At worst, it leads
      to the creation of a new TrackerDBInterface, with the initialization
      cost involved.
      Serializing this work, we're more likely to reuse a TrackerDBInterface
      and a pre-compiled statement from previous runs.
  12. 17 Oct, 2020 2 commits
  13. 16 Oct, 2020 1 commit
  14. 15 Oct, 2020 1 commit
  15. 14 Oct, 2020 2 commits
  16. 13 Oct, 2020 2 commits
  17. 12 Oct, 2020 1 commit