cursor prefetch with bounded lag
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 15/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- postgresql, python
- Ambito
- backend-api-design, databases
Direzione di ricerca
Inizia verificando la limitazione di pgwire indicata nell'issue e riesaminando l'API del cursore esistente descritta nel report. Non vengono indicati file o test e il comportamento richiesto potrebbe non essere implementabile; per completarlo sarebbero necessari un design confermato e supportato dal protocollo, nonché un ambito di progetto corrispondente.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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!
- Lingua principale
- Python
- Stelle
- 8.1k
- Fork
- 469
- Merge medio
- 2g 20h
- PR unite (30g)
- 9
Guida per i contributori
Nessuna guida per i contributori indicizzata per questo repository
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MagicStack/asyncpg
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
MagicStack/asyncpg#1357 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 48/100
MagicStack/asyncpg#1354 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
MagicStack/asyncpg#1342 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 56/100
MagicStack/asyncpg#1340 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 28/100
MagicStack/asyncpg#1337 ·
Tutte le issue di MagicStack/asyncpg
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
canonical/paas-charm#368 · 1 commento ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
tech debt
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
addition to tracking list Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
StevenBlack/hosts#3256 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 90/100
qualcomm/qai-appbuilder#275 ·