On 2009-11-14 09.14, Niclas Hedhman wrote:
Confirmed! I made the change suggested above and suddenly things are 'faster'. I wouldn't say "fast", because we are still in the 200-300ms range for the first 'find', then drops to ~20-40ms, on my machine. Removing the DISTINCT half the response times as well.But of course, we will have some problems with this, since the implementation could just have been; FILTER ( ?v1 = 'Lead1' || ?v1 = 'Lead99999' ) or FILTER ( ( ?v1 = 'Lead1'&& ?v2 = 'Available' ) || ?v1 = 'Lead9812' ) and so forth. IMHO, the query optimization is the responsibility of the Sesame and not us, and that this is indeed a worrying situation, something that I have brought up in the past, but not really pushed as hard as I should have.
I agree that this is Sesames problem. I'll take it to their mailing list and see what they say.
What are our choices? 1. Ignore it.
I can't. It's not good enough.
2. Try to optimize common cases, and recognize certain patterns and create a query accordingly.
One question is why the FILTER approach is used for the above. It could be possible to skip the FILTER, which would make a huge difference.
3. Engage some Sparql expert.
Which are few and far apart.
4. Try to use one or more other Sparql implementations.
I'm all for this. We should try other RDF databases and see if they work better.
5. Use Sesame with another query language, that may have better optimization support.
That would be SerQL. Definitely an option. It's an internal implementation detail anyway.
6. Make a SQL implementation.
This is an option too. Would we do it the one-table-way? Or base it on the Hibernate version? Or what?
7. Make a Lucene implementation.
This is definitely of interest. I need Lucene integration anyway in StreamFlow.
8. Make a Neo4j implementation.
jo...@neo is almost done with the EntityStore, so yes, an EntityFinder implementation would be the next logical step.
9. Something else.
What is the status of Named Queries? That would always be an option I think.
10. All of the above.
Except 1... /Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
