TABLE dateformat(file.mtime, "dd MMM HH:mm") as Updated, status
FROM #task
WHERE status.status-type != "completed"
WHERE !contains(file.path, "Templates")
WHERE priority = [[]]
SORT file.mtime DESC
This query results in 107 results - it freezes my OBS for ±5-10 seconds (also if I accidentally hover over the page with this query)
Am I missing something? Is there a trick to prevent this? Of course I know about LIMIT, but not something I wanna use unless it’s over 500 items.
I’m unsure how Dataview handles multiple WHERE … did you try using AND instead?
Do not understand your query, so I’m just guessing with this one …
```dataview
TABLE dateformat(file.mtime, "dd MMM HH:mm") as Updated, status
FROM #task
WHERE status.status-type != "completed"
AND !contains(file.path, "Templates")
AND priority = [[]]
SORT file.mtime DESC
```
This is a query that shows on my Low page (each priority is a page, so any task status/priority/any_value becomes clickable).
Using AND did improve opening the page a bit, but everytime I hover over (often accidentally) “Low” still freezes OBS. I like the hovering though, not something I’d want to disable…
The main page is loading in ±1 second with AND (was a bit tricky to test, because as soon as I try to click the page, it already freezes because of the hover preview that already started rendering) .
So it seems the previews are the main culprit here? Not sure how to debug this?
You can implicitly reference the current file via [[#]] or [[]], i.e. [[]] lets you query from all files linking to the current file.
But I’m afraid of this sentence “[[]] lets you query from all files linking to the current file.”. Can you try with [[#]]. But could be the same. I guess that it’s checking every linked file …
The WHERE data command will only keep those lines from the result set which match a given condition. This means that, unless all data in the result set matches the condition, this command will pass on a smaller result set to the next line than it received from the previous line. Unlike in SQL, you can have as many WHERE commands as you like.
Theoretically it should work (like it did), but using AND may be better for performance (as we just learned). It would be really helpful if we somehow could see how long every line in the query took to complete, especially if optimising queries becomes important (large datasets…?).
I have the same question as 