0.10.3 is released with query optimizer improvements https://github.com/datalevin/datalevin/blob/master/CHANGELOG.md#0103-2026-01-27
Quick question that I'm stumped on and I think I'm just missing something silly. This should probably be an or-join but I can't seem to make that work. The following rule works but the performance is bad (2s):
[(entity-area' ?area ?room)
(or
;; Check for room within continuous area w/ quadrants
(and
[?area-or-quad :locations ?room]
[?area :quadrants ?area-or-quad])
;; Check for room within discrete area locations (no quadrant)
(and
[?area-or-quad _]
[?area :locations ?room]
[?area :area-type :discrete]))]
I know the [?area-or-quad _] is the performance problem. How do I rework this? (or-join [?area ?room]... runs quickly but returns nil .what does this do [?area-or-quad _] you probably don't need it?
Use or-join and remove [?area-or-quad _]
or-join branches can use different sets of variables, so you do't need to include ?area-or-quad
The way to think of or-join, is to think each of its branches as a sub-query. The interface between these sub-queries and the main query is the argument list. These sub-queries are also independent.
or-join is optimized, so it normally performs much better than actual sub-queries, where a full query is run for each tuple, so it's quite expensive.
Ok thanks so much! I was able to solve the rule with:
[(entity-area ?area ?room)
(or-join [?area]
;; Check for room within discrete area locations (no quadrant)
(and [?area :locations ?room])
;; Check for room within continuous area w/ quadrants
(and [?area :quadrants ?area-or-quad]
[?area-or-quad :locations ?room]))]you can get rid of the first and, as it only has one triple pattern, a naked triple pattern there works
haha right of course. I think it was leftover from something else I was trying. Appreciate it. Really excited for the new releases. I've been working on my project a long time and need to upgrade
It is fully persistent MUD using datalevin as the database
cool:+1:
Wrote a piece on SQLite https://yyhh.org/blog/2026/01/sqlite-in-production-not-so-fast-for-complex-queries/