Report which extension codec handled each node of a serialized plan

Aperta
#1,706 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
python

Direzione di ricerca

Inizia con SessionContext.logical_extension_codec_ids() e physical_extension_codec_ids(), quindi leggi la catena di codec di estensione descritta in #1678. Determina come viene rappresentato un piano serializzato per EXPLAIN e definisci come il codec vincente possa essere attribuito a ogni nodo; il lavoro è completato quando un’ispezione specifica del piano o un risultato di EXPLAIN identifica il codec che gestisce ogni nodo serializzato.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Extension codecs compose as of #1678: a session holds a chain of them, and encoding walks the chain in install order until one claims an object. With several libraries installed there is currently no way to ask which codec handled a given node. Raised in https://github.com/apache/datafusion-python/pull/1678#pullrequestreview-4940081598.

Part of this is answered already. SessionContext.logical_extension_codec_ids() and physical_extension_codec_ids() list what is installed, in install order, and those ids are what a payload carries — so a decode failure names the codec that wrote the bytes and lists what the session actually has. What is missing is per-call attribution: which codec handled which node of a particular plan. Today the only way to find out is to check a codec's own call counters before and after, which requires the codec to expose them and tells you nothing about which node was involved.

Describe the solution you'd like

Surface the winning codec per node, most naturally in EXPLAIN output for a plan that has been serialized, or failing that as an inspection call that reports the encode decisions made for a given plan.

Describe alternatives you've considered

Leaving it to the decode error, which already names the responsible codec. That covers the case where something went wrong but not the case where someone is trying to understand a working setup, which is when a multi-library chain is most confusing.

Logging each claim at debug level. Cheap to add and much weaker: it is per-session rather than per-plan, and it puts the burden of correlating lines with nodes on the reader.

Additional context

Deliberately left out of #1678: recording the winner means threading it through plan formatting, which is a change to how plans are displayed rather than to how codecs compose.

Lingua principale
Python
Stelle
605
Fork
176
Merge medio
1g 23h
PR unite (30g)
8

Guida per i contributori

Nessuna guida per i contributori indicizzata per questo repository

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/datafusion-python

Tutte le issue di apache/datafusion-python

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.