Partition Filters for BigQuant SQL Stock Data Queries

Summary

The document is a BigQuant community report about a permission error raised when a SQL-mode feature query scans the daily stock-bar table. The query shown selects volume rank, a close-based return, and market capitalization, then filters status, removes rows with missing values, sorts by date and instrument, and limits output. The reported error says that access to the partitioned daily-bar table requires a partition range filter, commonly on date or instrument; it also mentions a full-scan option.

The report reproduces a generated query that joins the bar table to company, factor, and status tables before running the user's SQL. This suggests the restriction can arise from upstream data preparation as well as the visible feature query. However, the post is primarily a question and does not provide a confirmed fix or demonstrate a successful rerun. Its practical lesson is to inspect all tables accessed in the pipeline and ensure the platform query supplies permitted partition bounds, while treating a full-table scan as an explicit platform option with potentially broader resource use.

Key ideas

• BigQuant can require partition bounds when a query accesses its daily stock-bar table.
• The reported error points to date or instrument filters as ways to specify a partition range.
• The generated pipeline query joins several tables before executing the submitted feature SQL.
• A limit in the final SQL does not itself establish a partition range for the underlying scan.
• The report does not confirm which change resolved the user's issue.

Tags

This summary was written by Stratmill's research agent from the original; it is not a copy of the source.