Logseq Simple Queries - All the basics to filter what you need

Logseq simple queries hinge on one idea: build filters by combining functions (like task) with operators (like and/or/not) inside the required curly-brace query structure. Once that mental model clicks, tags, priorities, date ranges, and custom properties can be turned into fast, reliable views—without hand-editing complex logic every time.

At the foundation is the query syntax: typing “/query” opens the query builder, where the core layout is curly brackets with the query inside. The builder can insert the needed structure automatically, so memorization isn’t the goal. More important is how functions and values work together. In Logseq’s query language, a function takes a value—so filtering tasks looks like using the task function with a target status (e.g., “to do” or “done”). A common failure point is placing curly brackets incorrectly or forgetting them, which can cause the system to treat a filter like a literal search term instead of a function.

The practical workflow starts with references and tags. For example, tasks can be tagged with contexts using GTD-style “@” tags such as “@home.” A simple query can then pull tasks that are both referenced to “home” (via page references) and have the task status “to do.” The transcript emphasizes how the query builder’s live view helps reveal what’s happening: an outer reference to “home” pairs with a task function, and an and operator forces both conditions to be true. Changing a task’s status immediately changes whether it appears—tasks marked “done” drop out when the query requires “to do,” and can be brought back by adjusting the query to include additional statuses.

Priority filtering builds on the same mechanics. Tasks tagged with Priority A/B/C can be combined with earlier context and status filters so that only tasks matching all required tags appear. The builder’s logic is cumulative: adding Priority A narrows results further, and switching to Priority B expands or changes the set depending on the operator logic. For ordered task lists, the approach recommended is to create multiple queries (e.g., one for Priority A, another for Priority B) and stack them in the page in the order they should appear, rather than jumping straight into advanced sorting.

Date-based filtering uses the between operator, which is tied to journal dates. Tasks without journal dates won’t show up in date-range queries until they’re created on a dated journal page. For relative ranges, the transcript notes a limitation: the query builder can’t use “related dates” like “-7D” directly, so date math may need to be written in code (e.g., “minus seven days” to “today”).

Properties are the next major power feature. Block properties (like system = Xbox/PlayStation) let queries slice tasks by structured metadata, and results can be rendered as tables showing which property values matched. Page properties extend this for time-series tracking: a journal template can store hours worked as a page property, and a page-property query can list hours by date so timesheets can be filled quickly. Finally, operators—and, or, and not—control how conditions combine: and requires all matches, or accepts any, and not removes items (useful for excluding clutter or completed items). Debugging guidance is pragmatic: if nested logic breaks, break the query into smaller pieces and keep nesting shallow (roughly two layers) before resorting to advanced queries.