I'm not at a pc right now, but I think we switched to using prefers-color-scheme so you would need to change your OS/browser preferences

yes. Better to add an option on the webpage

I don't disagree, personally 🙂 thanks for the feedback!

@UGC0NEP4Y Out of curiosity, under what circumstances do you want your desktop in dark mode but the website in light mode? We can add a toggle but I'd really like to hear a strong justification from someone before we do it. It was a pretty active choice not to include one and default to the user's operating system choice. The reasoning here is perhaps somewhat personal: for those of us (like me) who require dark mode to use a computer at all, it's an accessibility issue and it is always best if the setting is globally controlled.

I am fine with dark mode of a web page. It’s just the dark mode of xtdb site is of a super high contrast, and reading it is a pain for my eyes (personal feeling) .

@U01AVNG2XNF To be honest, content-wise, the new web makes the content much more organized and accessible.

> super high contrast, and reading it is a pain for my eyes Ah, that's completely fair. It is quite a high-contrast dark mode and we may have leaned too far in the "accessibility" direction and not enough toward "night-time viewing." 😉 I'll add a task for us to look into adding a toggle.

@UGC0NEP4Y Glad to hear you like it! This was really just Phase Zero: get stuff shovelled into neat piles... like the first stage of cleaning out an old garage. 😉 We have plenty of new documentation and articles to come, once we start finding our feet.

so in essence I have :where [(some-rule ?c) [parent :child ?c]] being slow, but if change it to :where [(some-rule ?c) [parent :child ?x] [(= ?x ?c)] I get a massive speedup

7500ms => 2ms

So you're intentionally trying to use the triple clause as a kind of filter?

I've seen the same thing, just to add 2c (yes trying to use the triple clause as a filter)

yes, both the rule and the triple clause will filter the results

I have a UI page that allows users to search with many different search filters (any combination of one or more), so it's difficult to add workarounds because the different where clauses are dynamic

looking at the plans, the var-cardinality for ?c explodes to huge number 1.798E308 in the slow case... in the fast case it is 109.15

ah, yes that is Double/MAX_VALUE

that looks like it is used as a default/fallback in xtdb.query/triple-joins

the value seems to come from the cond in line 629 clause ignore-v?

even if I override the ignore-v? to false, the cardinality is too large

I can't explain the full story here, but at least part of it is because in the slow case ?c appears twice (whereas parent only appears once), and therefore it will be assumed that it is best to start from there in the join order. The exact heuristics here are a lot more involved that though, so it's hard to be sure. I will add this example & workaround to the linked thread in case it helps others.