Cool! Thanks for pulling this analysis together https://gist.github.com/zeitstein/8ba5c6c05583a75eee234e474e79d0ff#file-absenceq-clj-L48-L51 I haven't thought about it too deeply, but shouldn't this be inverted, i.e.:

(defn q-explicit2 []
  (xt/q (xt/db absnode-explicit)
    '{:find [e]
      :where [[e :even? true]
              (not [e :query? false])]}))

The idea is to have :query? false for those divisible by 100 in both cases, while the explicit case sets :query? true for rest and queries for it. I do check whether the results are the same in both cases. (Hopefully I've not completely lost my mind :)) Is this result surprising to you at all? I was under the impression absence queries are a problem. Maybe it's the example.

My brain is pretty fried today. I'll have to have another look tomorrow. > I was under the impression absence queries are a problem IIRC the real performance challenges arise when joining in the presence of multiple potential absences (at least)

I didn’t even notice the “experimental” in the docstring, I’ve been using it and it works fine

Ah, so the existence of the word "experimental" here is completely untrue. The API is pretty rock solid at this point. Thanks for mentioning it though - I'll make sure we clarify the docstring for the next release! (I've added a note to the project board)

btw, what I often look for in any listener adding functions: what I’m allowed to do in the handlers, like is it using some threadpool that could be exhausted if my listeners block or do something long running

that would be valuable info in the docstring imo