リファレンス
実行時の上限
実行できるプログラムには、量に関わるものすべてに有限の上限があります。上限は「最初のN件をください」という要求ではありません。超えた場合は保護された処理をエラーとして失敗させ、切り詰めたり、一部を完全な結果として返したりすることはありません。各環境で現時点にどの形が動くかは実装状況にあります。
上限はどこから来るか
| 出どころ | 例 |
|---|---|
| プログラムの証明 | LIMIT 10 や、証明された一意キーが、後続のレコード数を限定する。 |
| 作者のガード | JOINの MAX_OUTPUT_ROWS n、INFER の MAX ITEMS n、--params から束縛したガード。 |
| Connectorの契約 | 読み取り元のページサイズと最大件数。Effectのリクエストあたりの最大項目数。 |
| 言語の法則 | decimalの精度38のような固定の上限。 |
| Hostのポリシー | 運用者がHostに設定する容量の上限。 |
有効な上限は、該当する候補のうち最も小さいものです。作者のガードがほかのどれよりも厳しければ、それが拘束する上限になります。そうでなければ保持され、現時点では拘束していないと報告されます。計画（actql explain --json）は、解決されたすべての上限をその出どころとともに示します。
既定の上限
| 量 | 既定 | 決めるもの |
|---|---|---|
ローカルの VALUES プログラムの件数 | 100（最大10,000まで設定可能） | Hostのインストール設定（SDKでHostを作るときの installation オプション valuesMaxRows） |
| Runあたりに読み取り元から読む件数 | Connectorの契約 | Connector |
| Runあたりに読むバイト数と処理の総量 | Hostの容量ポリシー（既定のローカルプロファイルでは512 MiB） | Host |
INFER あたりのLLM呼び出し数 | レコード数。MAX ITEMS があればそれが上限。件数が上限を超える場合は1回も呼ばない | プログラムとConnector |
| LLMの再試行 | 一時的な失敗だけ。回数は固定の範囲内 | 言語の法則 |
| JOINが出力するレコード数 | 指定があれば MAX_OUTPUT_ROWS、なければHostの容量ポリシー | プログラムとHost |
| Effect Setあたりの項目数 | Connectorの契約 | Connector |
| Resultの読み取り応答 | 1回の読み取りで既定1 MiB、最大16 MiB | クライアントのオプション |
| クエリテキスト | 固定のデコード後サイズとトークンの予算 | 言語の法則 |
作者のガード
ガードは、作者がプログラムに足す正の整数で、リテラルかパラメーターで書きます。JOIN … MAX_OUTPUT_ROWS 1000、INFER … MAX ITEMS 500 のほか、演算ごとのガードが言語の仕様にあります。証明や上限の方が厳しい場合でもガードは保持されるので、レビューする人は作者の意図を確認できます。
上限がしないこと
- レコードを選ぶことはしません。
LIMITは選びますが、ガードは失敗させるだけです。 - Hostが変わっても意味は変わりません。変わるのは、そのプログラムを実行してよいかどうかだけです。
- 外部システムが応答することを約束しません。有限の処理でも応答を待つことはあり、不明な結果はタイムアウトで失敗にするのではなく、突き合わせます。
これらの上限が実現している保証については、実行モデルと保証を参照してください。
Source: actql/actql/docs/reference/limits.md at d904416674e4 · Edit on GitHub