Re: InsertPic_(12-07(12-07-21-26-31)

Ok, thanks for the explanation. > not separate partitions on disk for each graph I wrote " 'partitions' or 'tables' " but I had the TDB files in mind (GOSP.dat + GOSP.idn), it was a wrong analogy... > you are reducing the number of tuples over which the filter has to scan by narrowing its

Re: InsertPic_(12-07(12-07-21-26-31)

No, I don't think that's what's going on. Andy can correct me if I'm going wrong here, but TDB builds the equivalent of a quad table for named graphs, not separate partitions on disk for each graph. The exception is the default graph. The same is true for TIM, Jena's transactional in-memory

Re: InsertPic_(12-07(12-07-21-26-31)

> $word is provided as a value? $word looks like a variable to the optimizer so the FILTER is after the whole of the BGP. Sorry I should have written" : FILTER(REGEX(?title, "some word", 'i')) my '$word' meant 'any value to complete the query string'. > With GRAPH, or using just the {} part,

Re: InsertPic_(12-07(12-07-21-26-31)

On 17/12/2018 07:53, Vincent Ventresque wrote: Are you sure that named graphs have better performance? I'm not a specialist, and I'd like to know other users' opinion about that question. I thinks it depends both on the structure of your data and the queries you run. My use case consisted

Re: InsertPic_(12-07(12-07-21-26-31)

Are you sure that named graphs have better performance? I'm not a specialist, and I'd like to know other users' opinion about that question. I thinks it depends both on the structure of your data and the queries you run. My use case consisted in using a dataset with +/- 168 M triples,

Re: InsertPic_(12-07(12-07-21-26-31)

LIMIT 10 doesn't limit very much in the query. It applies after the group and count have happen - it's a limit on the results requirned, not the work done in this query, It has to do all the WHERE part in order to calculate the COUNT. The query is returning any old 10 items (there is no

Re: InsertPic_(12-07(12-07-21-26-31)

OK. I explain my project in the following The KG schema is composed of a set of semantic types like disease or drugs, and a set of relations like treated_by(disease, drug). Then each instance relation, like treated_by(disease_1, drug_1) has an annotation property 'year' which means this

Re: InsertPic_(12-07(12-07-21-26-31)

Hello, I'm curious if slightly changing the SPARQL query can have an impact on performance, maybe you could try something like: where { ?object MKG:English_name 'Pyrilamine' . ?RelAttr owl:annotatedTarget ?object ; owl:annotatedSource ?subject ;

Re: InsertPic_(12-07(12-07-21-26-31)

Let's slow down here a bit. We can't give you any reasonable advice until you tell us _much_ more about your work. What is the data like? What kinds of queries are you doing? How are you running them? What do you expect to happen? Please give us a great deal more context. ajs6f > On Dec 7,

Re: InsertPic_(12-07(12-07-21-26-31)

I store the 1.4B triples in two steps. Firstly, I made 886 rdf files, each of which contains 1615837 triples. Then, I upload them into TDB using Fuseki. This is a huge job. Are you sure that named graphs have better performance? Then how to build named graphs? On 12/7/2018 23:48，Vincent

Re: InsertPic_(12-07(12-07-21-26-31)

Do you mean -Xms = 64G ? N.B. : with 1.4 B triples, you should have better performance using named graphs. Le 07/12/2018 à 16:37, 胡云苹 a écrit : > My memory is 64G and my setting is no upper limit. > On 12/7/2018 23:34，Vincent Ventresque > wrote： > >

Re: InsertPic_(12-07(12-07-21-26-31)

My memory is 64G and my setting is no upper limit. On 12/7/2018 23:34，Vincent Ventresque wrote： Hello How do you run fuseki? you can increase java memory limit with java options : java -jar -Xms4096m -Xmx4096m fuseki-server.jar (where 4096m = 4 Go, but could be 8192m or more) N.B. : I'm