Report which extension codec handled each node of a serialized plan

オープン
#1,706 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
python

調査の方向性

SessionContext.logical_extension_codec_ids() と physical_extension_codec_ids() から始め、続いて #1678 で説明されている拡張 codec チェーンを読みます。EXPLAIN 用にシリアライズされたプランがどのように表現されるかを判断し、各ノードに勝者となった codec を割り当てる方法を定義します。完了条件は、プラン固有の検査または EXPLAIN の結果によって、シリアライズされたすべてのノードを処理する codec を特定できることです。

索引モデルが issue の本文から書いたものです。

説明

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.

主要言語
Python
スター
605
フォーク
176
平均マージ
1日 23時間
マージ済み PR(30日)
8

コントリビューションガイド

このリポジトリのコントリビューションガイドは索引されていません

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

apache/datafusion-python のほかの issue

apache/datafusion-python の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。