This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-12-09
Channels
- # adventofcode (93)
- # announcements (11)
- # babashka (7)
- # babashka-sci-dev (17)
- # beginners (73)
- # biff (7)
- # calva (3)
- # cider (1)
- # clj-kondo (160)
- # clj-together (12)
- # clojure (44)
- # clojure-art (2)
- # clojure-europe (12)
- # clojure-losangeles (1)
- # clojure-nl (3)
- # clojure-norway (22)
- # clojure-uk (2)
- # clojurescript (8)
- # clr (1)
- # cursive (6)
- # data-science (1)
- # datomic (1)
- # emacs (6)
- # events (1)
- # exercism (1)
- # fulcro (6)
- # graphql (2)
- # introduce-yourself (1)
- # lsp (18)
- # nrepl (7)
- # off-topic (45)
- # polylith (25)
- # portal (25)
- # practicalli (3)
- # re-frame (14)
- # reagent (28)
- # reitit (2)
- # releases (2)
- # shadow-cljs (73)
- # sql (11)
- # tools-deps (12)
- # transit (4)
- # xtdb (4)
thank you for your feedback @tatut @taylor.jeremydavid! for now I probably go with 3 queries, as suggested by Tatu ( https://gist.github.com/jehaby/7d58955955566ea32e9d94f8667f38f3#file-xtdb-lucene-clj-L3-L50 ) it works quite well for expected size of the dataset although I’m not sure I understand why approach with single query runs 10 times slower ( https://gist.github.com/jehaby/7d58955955566ea32e9d94f8667f38f3#file-xtdb-lucene-clj-L52-L89 ) is it possible to achieve the same speed with single query? PS: I haven’t tested both queries thoroughly yet, so some bugs might be present. i’ve also be happy to get any suggestions for possible improvements of readability and performance.
it's hard to analyze exactly what's going on without access to the sample data, but I suspect there's some aspect that's making the rules fire multiple times (they execute as non-lazy subqueries) and therefore it would be repeatedly running the same lucene searches