How to use queries in Logseq

Logseq queries turn note retrieval into repeatable, parameter-driven “database questions,” letting users pull exactly the blocks they need—then save those searches as blocks for quick reuse. That matters because the real payoff in Logseq comes from fast, targeted resurfacing of information; when retrieval is precise, notes shift from a one-way feed into a feedback loop that supports writing, planning, and review.

At the core, queries are Logseq’s most directed retrieval method. Instead of relying only on Control K search, queries can specify criteria such as tags, backlinks, task status, priority, and date ranges. They also save the query as a block, so the same retrieval workflow can be repeated later without rebuilding the logic.

A query returns three categories of results: (1) blocks linked to a backlink or tag, (2) blocks indented under those linked blocks—making indentation crucial for structuring data—and (3) all blocks on the page where the query runs (if any exist). This behavior is demonstrated using tags/backlinks, where a query for a hashtag returns the linked blocks and their indented children, while the page-level results can be empty depending on setup.

Query syntax is built around typing “/query” and then entering parameters. The transcript highlights built-in parameters that map to common workflows: task status via task (using parentheses rather than square brackets), priority via priority (with Logseq’s three priority levels A, B, and C), and time filtering via between (including relative ranges like “yesterday” to “today,” and offsets such as “minus one day” or “minus one year”). For more complex retrieval, Boolean logic—using operators like and, or, not, and all—lets users combine conditions. A practical example pairs task status “to do” with priority “A,” using nested parentheses to keep the logic unambiguous.

Several usage tips focus on making queries maintainable and fast. Users are encouraged to add a user-friendly description block above each query and collapse it so the database reads like documentation. Text queries are especially valuable when information isn’t linked: wrapping terms in inverted commas returns matching blocks quickly, and the transcript warns that text queries are case sensitive. Performance is another constraint: queries that return too many blocks can slow Logseq dramatically, so broad queries should be used carefully.

For readability, query results can be pivoted into tables when block properties are used consistently, enabling structured “index” pages such as an articles namespace populated via properties. The transcript also gives concrete dashboard-style examples: a task dashboard that filters high/medium priority tasks, a “query while writing” setup that surfaces prior feedback tagged to a colleague for reference during drafting, and code-focused text querying for CodeMirror blocks (with an emphasis on consistent lowercase naming due to case sensitivity).

Finally, queries are positioned as a complement to search rather than a replacement. They’re most useful for aggregating information into a consistent place (like compiling feedback), building dashboards and repeatable pipelines, finding text across unlinked references, and creating index-style views over time—such as revisiting the same date across the last 12 months or last 10 years using date-range queries. The transcript closes by noting that Boolean logic is covered in more depth elsewhere, while properties/metadata are a natural next topic for deeper, table-friendly indexing.