Sure. Sorry to transgress. In this case, since the very same query (structurally) had very different performance characteristics depending on which string was used to match a literal, I jumped to a conclusion. In particular, I'm assuming that the nature of OPTIONAL is that the 'required' part constrains the second part, I didn't think that I was inventing something like that.
I would point out that JIRA is a convenient way to pass files around; would a JIRA not marked 'bug' have been more friendly? On Thu, Feb 3, 2011 at 4:47 PM, Andy Seaborne <[email protected]> wrote: > Hi, > > Could we have things like slow queries on the user list to start with, > please? If there's an underlying issues, then move to JIRA but until there > is an addressable issue, JIRA does not work for me for discussing query > design. It's quite possible in SPARQL to write very expensive queries, > > SELECT * { ?s ?p ?o . ?x ?y ?z } > > and ARQ/TDB's design means such queries will execute and finish eventually. > But its N^2 results on a database of N. And N tends to be a decently large > number. In fact, it wouldn't even use very much memory for that query, > because of internal streaming. > > Andy > > On 03/02/11 15:52, Benson Margulies (JIRA) wrote: >> >> [ >> https://issues.apache.org/jira/browse/JENA-40?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990142#comment-12990142 >> ] >> >> Benson Margulies commented on JENA-40: >> -------------------------------------- >> >> Changing the OPTIONAL's to UNION and adding the necessary constraint to >> both of them also makes it run in reasonable time/ >> >> >>> Query that runs more or less forever >>> ------------------------------------ >>> >>> Key: JENA-40 >>> URL: https://issues.apache.org/jira/browse/JENA-40 >>> Project: Jena >>> Issue Type: Bug >>> Components: TDB >>> Reporter: Benson Margulies >>> Attachments: r.rq, yk.txt >>> >>> >>> Using the data set you have from me, the following query, which looks >>> very much like a series of other queries that run quite rapidly, shows no >>> sign of finishing. >> >
