Hi, there are no immediate plans to change this behaviour, although I have certainly experienced the same thoughts/questions. The reasoning behind the current behaviour is that it is an accurate implementation of the axioms of Datalog. The [(any? x)] clauses definitely could be inferred/auto-generated, but I imagine there may be occasions during development where, being implicit, that makes things more confusing (despite the reduced line count) - it is probably worth experimenting with something like this in userspace though. Alternatively, an option could be added to the query like :ignore-non-matching-rule-leg-vars true Another thought is that we could add a built-in pred, equivalent to any? but that accepts varargs (which clojure.core/any? sadly doesn't), that way you could at least consolidate everything into a single clause [(any? x y z)]

The latter would definitely be a nice bit of sugar. I might just implement my own version of this for now.

Cool, I'll be curious to see what you come up with! We should probably create a more permanent issue or GH discussion to track this though - would you like to do the honours? Otherwise I'm happy enough to just briefly copy and paste these notes myself

Happy to do it. Done.

'Afternoon! We generally recommend RocksDB as the default, for a variety of reasons (stability, support, ingestion performance etc.), unless you really need the fastest possible query performance, in which case you may want to consider LMDB. We don't have any super detailed documentation on the comparison today, unfortunately, but I would always strongly recommend doing some benchmarking against your use-case anyway (and take a look at our bench subproject if you are looking for code to borrow!).

Thanks for the reply. I'm doing a bit of benchmarking as we speak! RocksDB seems to be quite a bit more space efficient than LMDB. Y axis is the size of the index store on disk in KB. In E1, I've batched inserts into 10,000 PUTs per transactions, in E2 I have one PUT per transaction.

> LMDB doesn't have any built in compression support at all. TIL, via http://www.lmdb.tech/bench/inmem/compress/LMDB/ Nice graph 🙂

is there some known instability in LMDB?

Not as such. It's just a bigger unknown (fewer users, tiny core dev team) even though the code base is technically much smaller & simpler

lmdb will almost certainly be substantially more stable for basically the reasons refset listed but it's not as commonly used with XT I gather so it will probably be a worse experience. Though I think the fancy upcoming indexes don't use either so it's probably not worth worrying about?

I've been using it and it has "just worked" though I don't have experience with larger databases or heavier load

> lmdb will almost certainly be substantially more stable for basically the reasons refset 😄 very fair! > the fancy upcoming indexes don't use either so it's probably not worth worrying about? Kind of, although we can't make promises about the future release plans yet, so anyone looking to put something into prod in the meantime still needs to give this some thought & testing