Yes it is simply the pile of data that is too large.
When I limit the initial query to less data it works fine.
I do wonder if use of the not is better in this case.
- it limits the data in the query result
- at what (performance) price?
- Is that price due to the way the query is written
- or just because of the huge amount of data we try to subtract from each other
- it saves on (double) sorting and grouping after the fact.
The only question is, can I get it to work on my large data set. I will have to (carefully!) test your suggestions.
This works, and performs about equal to my working solution.
The moment I change it to work with the full year of 2024 it crashes Logseq.
#+BEGIN_QUERY
{:title [:b.h.dark "Laatste keer dit jaar"]
:inputs ["hobby" "202407"]
:query [:find (pull ?p [*])
:in $ ?qpage ?dag %
:where
[?a :block/name "activiteit"]
[?p :block/properties ?prop]
[(get ?prop :cluster) ?cluster]
[(= ?cluster ?qpage)]
[?p :block/name]
(not
[(get ?prop :status) ?status]
[(= ?status "archief")]
)
(check-ref ?b ?p)
[?b :block/path-refs ?a]
[?b :block/page ?j]
[?j :block/journal-day ?d]
[?j :block/original-name ?journal]
[(str ?d) ?jd]
[(subs ?jd 0 6) ?journaljaar]
; [(str ?dag) ?strdag]
; [(subs ?strdag 0 4) ?jaar]
[(= ?journaljaar ?dag)]
(not-join [?a ?d ?p]
[?x :block/path-refs ?a]
[?x :block/page ?jx]
[?jx :block/journal-day ?dx]
[(> ?dx ?d)]
(check-ref ?x ?p)
)
]
:rules [
[(check-ref ?b ?p)
(or-join [?b ?p]
[?b :block/refs ?p]
(and
[?p :block/original-name ?hobby]
[?subp :block/properties ?prop]
[(get ?prop :hobby) ?hobbyprop]
(or
[(= ?hobbyprop ?hobby)]
[(contains? ?hobbyprop ?hobby)]
)
[?b :block/refs ?subp]
)
)
]
]
}
#+END_QUERY