Fork me on GitHub
#xtdb
<
2021-10-25
>
pinkfrog13:10:45

Is it possible to toggle the dark background to white for the new-designed xtdb website? https://xtdb.com/docs/

refset14:10:12

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

pinkfrog15:10:35

yes. Better to add an option on the webpage

refset20:10:24

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

Steven Deobald16:10:07

@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.

pinkfrog12:10:58

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) .

pinkfrog14:10:17

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

Steven Deobald18:10:27

> 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.

Steven Deobald18:10:43

@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.

tatut15:10:36

I'm not sure, but I think https://github.com/xtdb/xtdb/issues/1533 it might be related to the same issue... I had a similar very poor query performance when using a rule with 2 legs (that was fast on its own) and adding another triple to constrain the result

tatut15:10:11

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

tatut15:10:16

7500ms => 2ms

refset17:10:14

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

xlfe02:10:57

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

tatut04:10:58

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

tatut04:10:37

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

tatut04:10:39

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

tatut04:10:36

ah, yes that is Double/MAX_VALUE

tatut04:10:07

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

tatut05:10:08

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

tatut05:10:03

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

refset16:10:40

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.