-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Query optimisation. #1240
base: skosmos-2
Are you sure you want to change the base?
Query optimisation. #1240
Conversation
Kudos, SonarCloud Quality Gate passed! |
Thanks for the PR @pulquero ! Can you explain what you did here in a bit more detail? Which operation was slow, and how much does the optimisation help? Are there any side effects that you are aware of? |
For my data it was milliseconds vs minutes. Added my observations as comments below:
|
Thanks for the details. It's still not entirely clear to me which operation was slow from the user perspective. The function in question (generateTransitivePropertyQuery) is a rather low level one and is used, indirectly, at least to generate the QL query used for querying breadcrumb paths in the web UI, but also for some of the REST API methods. It would be good to know e.g. which direction is relevant here (transitive broaders - like in the breadcrumbs - or transitive narrowers?) Also, what does your data look like? Is the hierarchy somehow big or complicated since the query ends up taking minutes? This hasn't been a big performance issue in the past for us, that's why I'm asking. Also, which triple store? We're using Fuseki mostly, but are you perhaps using GraphDB as in your other PR? |
I'm using graphdb, and my vocabulary consists of a million skos:Concept. It is in the default graph alongside other vocabularies and cross-referenced. I think the avg tree depth is about 3. I believe <$uri> a skos:Concept results in a cartesian product with ?object skos:prefLabel ?label matching everything in the entire default graph. |
No description provided.