cursor prefetch with bounded lag
还没有人认领这个 Issue。
评估
- 难度
- 5/5
- 预计耗时
- 一周以上
- 新手友好度
- 15/100
- Issue 类型
- 功能
- 描述清晰度
- 需要澄清
- 活跃度
- 停滞
- 技术栈
- postgresql, python
调研方向
首先验证 issue 中所述的 pgwire 限制，并审查报告中描述的现有游标 API。未指定任何文件或测试，并且所请求的行为可能无法实现；要完成此项工作，需要确认一种受协议支持的设计以及相应的项目范围。
由索引模型根据 Issue 内容生成。
描述
EDIT: nvm, looks like there's really no mechanism in the pgwire protocol that would support this behavior.
Would it at all be possible to support prefetching a batch of up to N rows via a cursor, as compared to waiting for exactly N rows to be available?
In other words, I would like to have a max_lag parameter similar to timeout, but with different semantics. If after max_lag at least 1 row, yet less than prefetch rows are available, do return the available rows.
Current api is:
cursor(query, *args, prefetch=None, timeout=None, record_class=None)
I would like it to be augmented as:
cursor(query, *args, prefetch=None, max_lag=None, timeout=None, record_class=None)
Is there any intrinsic limitation that would make this not worth the effort or simply there has been no interest for anything like that?
Thank you!
- 主要语言
- Python
- 星标
- 8.1k
- 派生
- 469
- 平均合并
- 2 天 20 小时
- 30 天内合并 PR
- 9
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
MagicStack/asyncpg 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 78/100
MagicStack/asyncpg#1357 · 1 条评论 · 1 个 reaction ·
-
难度 3/5 1-2 天 新手友好度 72/100
MagicStack/asyncpg#1342 ·
-
难度 3/5 1-2 天 新手友好度 56/100
MagicStack/asyncpg#1340 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 28/100
MagicStack/asyncpg#1337 ·
-
难度 4/5 3-5 天 新手友好度 42/100
MagicStack/asyncpg#1330 · 1 条评论 ·
查看 MagicStack/asyncpg 的全部 Issue
相似的 Issue
-
bug confirmed issue
难度 2/5 1-3 小时 新手友好度 75/100
open-webui/open-webui#30750 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
-
enhancement
难度 2/5 1-3 小时 新手友好度 75/100
OpenwaterHealth/openmotion-bloodflow-app#604 · 1 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
good first issue
难度 1/5 1 小时以内 新手友好度 90/100