M.schmidt00 added a comment.
OK, added this as a comment to http://trac.bigdata.com/ticket/1083, which deals
with the issue of filter pushing.
TASK DETAIL
https://phabricator.wikimedia.org/T96094
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsubscribe or !as
Thompsonbry.systap added a comment.
Ok. At that number this will not matter. But it is not being as efficient
as you would hope. Something to work on.
Bryan
TASK DETAIL
https://phabricator.wikimedia.org/T96094
REPLY HANDLER ACTIONS
Reply to comment or attach files, or !close, !claim, !unsu
Smalyshev added a comment.
Yes, the idea behind this query is to do prefix scan/filter on the IRIs. If
there's some syntax we'd be better using to achieve the same we could change
this query. In general, the amount of predicates from Q30 shouldn't be _that_
high (no more that hundreds) so it ma
Thompsonbry.systap added a comment.
This part could be expensive. Instead of having a prefix scan, it is
scanning all statements, materializing the Object position from the
dictionary, and then checking the string representation of that URI for a
match.
http://www.wikidata.org/entity/Q30 ?statem
Smalyshev added a comment.
So we actually moved to a different model of updating, now the query we use to
filter out the unused entries is:
DELETE { ?s ?p ?o } WHERE {
VALUES ?s { %values% }
# Since values are shared we can only clear the values on them when they
are no longer used
M.schmidt00 added a subscriber: M.schmidt00.
M.schmidt00 added a comment.
Generally speaking, the FILTER NOT EXISTS query is quite challenging, it
requires the evaluation of a composed graph pattern for each of the outer
solutions. What’s missing here for the query to run efficiently is a distin
