# "optional" slow query **URL:** \ **Category:** Support\ **Created:** [December 28, 2020, 6:06am UTC](https://community.stardog.com/t/optional-slow-query/2846 "2020-12-28T06:06:36Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![crapthings](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/crapthings/32/686_2.png) [@crapthings](https://community.stardog.com/u/crapthings)\ **Post date:** [December 28, 2020, 6:06am UTC](https://community.stardog.com/t/optional-slow-query/2846/1 "2020-12-28T06:06:37Z")
i've ~325k triple count fast ```auto SELECT ?definition ?broader ?narrower WHERE { :eca0a3b72707f78df864e19481e8ec92 a skos:Concept . OPTIONAL { :eca0a3b72707f78df864e19481e8ec92 skos:definition ?definition . } OPTIONAL { :eca0a3b72707f78df864e19481e8ec92 skos:broader ?broaderUri . # enable this line will be slow ?broaderUri skosxl:prefLabel ?broaderLabel . # ?broaderLabel skosxl:literalForm ?broader . } # OPTIONAL { # :eca0a3b72707f78df864e19481e8ec92 skos:narrower ?narrowerUri . # ?narrowerUri skos:prefLabel ?narrower # } } ``` slow the problem is when i add "?broaderUri skosxl:prefLabel ?broaderLabel ." into query its very slow my use case is not all "subject" has such "predict"(skos:broader or skos:narrower etc) ```auto SELECT ?definition ?broader ?narrower WHERE { :eca0a3b72707f78df864e19481e8ec92 a skos:Concept . OPTIONAL { :eca0a3b72707f78df864e19481e8ec92 skos:definition ?definition . } OPTIONAL { :eca0a3b72707f78df864e19481e8ec92 skos:broader ?broaderUri . ?broaderUri skosxl:prefLabel ?broaderLabel . # ?broaderLabel skosxl:literalForm ?broader . } # OPTIONAL { # :eca0a3b72707f78df864e19481e8ec92 skos:narrower ?narrowerUri . # ?narrowerUri skos:prefLabel ?narrower # } } ``` here is query plan ```auto Distinct [#34] `─ Projection(?definition, ?broader, ?narrower, ?broaderUri) [#34] `─ NestedLoopJoinOuter(_) [#34] +─ NestedLoopJoinOuter(_) [#34] │ +─ Union [#34] │ │ +─ Union [#5] │ │ │ +─ Scan[SPOC](:eca0a3b72707f78df864e19481e8ec92, rdf:type, ) [#1] │ │ │ `─ PropertyPath(:eca0a3b72707f78df864e19481e8ec92 -> ?bjbccztv, minLength=1) [#4] │ │ │ `─ Union [#2] │ │ │ +─ Scan[POSC](?bjbccztv, , :eca0a3b72707f78df864e19481e8ec92) [#1] │ │ │ `─ Scan[POSC](?bjbccztv, , :eca0a3b72707f78df864e19481e8ec92) [#1] │ │ `─ Union [#29] │ │ +─ PropertyPath(?jayatpds -> :eca0a3b72707f78df864e19481e8ec92, minLength=1, reversed) [#12] │ │ │ `─ Union [#6] │ │ │ +─ Scan[SPOC](:eca0a3b72707f78df864e19481e8ec92, , ?jayatpds) [#3] │ │ │ `─ Scan[SPOC](:eca0a3b72707f78df864e19481e8ec92, , ?jayatpds) [#3] │ │ `─ Union [#16] │ │ +─ PropertyPath(:eca0a3b72707f78df864e19481e8ec92 -> ?nqjentph, minLength=1) [#12] │ │ │ `─ Union [#6] │ │ │ +─ Scan[SPOC](:eca0a3b72707f78df864e19481e8ec92, , ?nqjentph) [#3] │ │ │ `─ Scan[SPOC](:eca0a3b72707f78df864e19481e8ec92, , ?nqjentph) [#3] │ │ `─ PropertyPath(?tsdwflim -> :eca0a3b72707f78df864e19481e8ec92, minLength=1, reversed) [#4] │ │ `─ Union [#2] │ │ +─ Scan[POSC](?tsdwflim, , :eca0a3b72707f78df864e19481e8ec92) [#1] │ │ `─ Scan[POSC](?tsdwflim, , :eca0a3b72707f78df864e19481e8ec92) [#1] │ `─ Scan[SPOC](:eca0a3b72707f78df864e19481e8ec92, , ?definition) [#1] `─ MergeJoin(?broaderUri) [#1] +─ Scan[PS_NOC](?broaderUri, , _) [#44K] `─ Scan[POSC](?broaderUri, , :eca0a3b72707f78df864e19481e8ec92) [#1] ``` ```auto Backup Storage Directory : .backup CPU Load : 0.64 % Connection Timeout : 10m Export Storage Directory : .exports Memory Heap : 874M (Max: 1.9G) Memory Mode : DEFAULT{Starrocks.block_cache=20, Starrocks.dict_block_cache=10, Native.starrocks=70, Heap.dict_value=50, Starrocks.txn_block_cache=5, Heap.dict_index=50, Starrocks.memtable=40, Starrocks.untracked_memory=20, Starrocks.buffer_pool=5, Native.query=30} Memory Query Blocks : 0B (Max: 373M) Memory RSS : 1.2G Named Graph Security : false Platform Arch : x86_64 Platform OS : Mac OS X 10.15.7, Java 1.8.0_251 Query All Graphs : false Query Timeout : 5m Security Disabled : false Stardog Home : /Users/monsterstep/dev/stardog_home Stardog Version : 7.4.5 Strict Parsing : true Uptime : 4 days 5 hours 4 minutes 56 seconds Databases : +----------+-------------+------------------------------------------------------+--------------------------------------------+ | | | Transactions | Queries | +----------+-------------+-------+-------+-----------+---------------+----------+---------+-------+---------------+----------+ | Database | Connections | Open | Total | Avg. Size | Avg. Time (s) | Rate/sec | Running | Total | Avg. Time (s) | Rate/sec | +----------+-------------+-------+-------+-----------+---------------+----------+---------+-------+---------------+----------+ | app | 0 | 0 | 6 | 565K | 8.445 | 0.000 | 0 | 661 | 26.001 | 0.002 | | demo | 0 | 0 | 0 | 0 | 0.000 | 0.000 | 0 | 20 | 0.002 | 0.000 | | lawtime | 0 | 0 | 0 | 0 | 0.000 | 0.000 | 0 | 8 | 0.000 | 0.000 | | test | 0 | 0 | 0 | 0 | 0.000 | 0.000 | 0 | 8 | 0.000 | 0.000 | +----------+-------------+-------+-------+-----------+---------------+----------+---------+-------+---------------+----------+ ``` ---
**Author:** ![jess](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/jess/32/10_2.png) [@jess](https://community.stardog.com/u/jess)\ **Post date:** [December 29, 2020, 12:19am UTC](https://community.stardog.com/t/optional-slow-query/2846/2 "2020-12-29T00:19:48Z")
Hi crapthings, Can you run `stardog-admin db optimize` and see if the performance and/or plan changes? ---
**Author:** ![crapthings](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/crapthings/32/686_2.png) [@crapthings](https://community.stardog.com/u/crapthings)\ **Post date:** [December 29, 2020, 4:48am UTC](https://community.stardog.com/t/optional-slow-query/2846/3 "2020-12-29T04:48:03Z")
@jess it looks good for this query in stardog studio 200ms ~ 300ms after optimize should i always run this command after ```auto stardog data add app x.ttl stardog-admin db optimize app ``` ---
**Author:** ![pavel](https://yyz2.discourse-cdn.com/flex030/user_avatar/community.stardog.com/pavel/32/18_2.png) [@pavel](https://community.stardog.com/u/pavel)\ **Post date:** [January 4, 2021, 10:30am UTC](https://community.stardog.com/t/optional-slow-query/2846/4 "2021-01-04T10:30:58Z")
No, that shouldn't be necessary after every update. We normally suggest it after bulk updates which modify a large amount of triples (esp. if large numbers of triples are deleted). It is unusual to see a very large performance drop on such a small scale (but again, performance is more a function of the total number of triples present, added, and deleted since the last `optimize`). If you could describe your updates, that could help us reproduce the issue. Also when one query plan is much faster than the other, we need to see both of them. Best, Pavel ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex030/uploads/stardog/original/2X/e/ed66b48a616f505106a4acde3c9cee7e6da9bc67.svg) [@system](https://community.stardog.com/u/system)\ **Post date:** [January 18, 2021, 10:30am UTC](https://community.stardog.com/t/optional-slow-query/2846/5 "2021-01-18T10:30:59Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.