On Thu, 2016-01-07 at 08:48 +, Håvard Mikkelsen Ottestad wrote:
> Hi,
>
> Reordering the filters might help.
I've tried a bit of this, without much noticeable effect. I understand
that these are pretty well optimized when the sparql text is converted
to algebra.
>
> Also, maybe a stats file
Thoughts inline:
On 07/01/2016 15:56, "Paul Tyson" wrote:
>Here is an actual query, partially obfuscated. It returns about 18K
>nodes in 40 seconds, from a dataset of about 17M triples. (The nodes are
>not necessarily distinct.)
>
>The predominant graph structure is like:
Here is an actual query, partially obfuscated. It returns about 18K
nodes in 40 seconds, from a dataset of about 17M triples. (The nodes are
not necessarily distinct.)
The predominant graph structure is like:
?node <- ?lsu -> ?detail -> LSUPROPERTYVALUE
Thanks for your attention and any
I have a modest (17M triple) dataset, fairly flat graph. I run some
queries selecting nodes with anywhere from 12-20 different property
values.
Result set counts are anywhere from 10,000 to 30,000 nodes. Total
execution time measured at client are in the 30-40 second range.
The web request
Hi,
Can you post a link to your dataset and queries?
If the data isn’t sensitive that is.
Regards,
Håvard M. Ottestad
On 06/01/16 17:17, "Paul Tyson" wrote:
>I have a modest (17M triple) dataset, fairly flat graph. I run some
>queries selecting nodes with anywhere
On Wed, 2016-01-06 at 18:52 +, Andy Seaborne wrote:
> Hi Paul,
>
> > My question is: is total query time limited by search execution speed,
> > or by marshaling and serialization of search results?
>
> Costs are a bit of both but normally mainly query. It also depends on
> the client
Hi Paul,
> My question is: is total query time limited by search execution speed,
> or by marshaling and serialization of search results?
Costs are a bit of both but normally mainly query. It also depends on
the client processing.
Some context please:
1/ What's the storage layer?
2/ What