Report which extension codec handled each node of a serialized plan

Abierto
#1,706 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
35/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
python

Línea de trabajo

Comienza con SessionContext.logical_extension_codec_ids() y physical_extension_codec_ids(), y después lee la cadena de codecs de extensión descrita en #1678. Determina cómo se representa un plan serializado para EXPLAIN y define cómo se puede atribuir el codec ganador a cada nodo; se considera terminado cuando una inspección específica del plan o un resultado de EXPLAIN identifica el codec que gestiona cada nodo serializado.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
605
Forks
176
Merge medio
1 d 23 h
PR fusionados (30 d)
8

Guía de contribución

No hay ninguna guía de contribución indexada para este repositorio

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/datafusion-python

Todos los issues de apache/datafusion-python

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.