Decide how to handle scalar collections

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

メンテナーはふだん 1 日以内に返信

@roji がすでに取り組んでいます。

2024年9月11日 から。

評価

この issue はまだ評価されていません。

説明

performance

When arrays get parameters (e.g. WHERE b.Foo = ANY ($1)), the cardinality of the array can be very important to choosing the right query plans; see https://github.com/dotnet/efcore/issues/32394 for numerous reports of regressions on SQL Server in 8.0, because of the switch from constants to OPENJSON there.

In PG we didn't have a translation change in 8.0 - the provider always parameterized arrays. However, the same sort of problem (inefficient plans due not taking array cardinality into account) can occur with PG as well; if Npgsql is configured to do auto preparation (which is recommended), then the query SQL may end up getting a generic plan; at that point, the query is stuck with a plan that has some arbitrary array cardinality (based on the first few executions presumably).

We could mitigate this by forcing PG to use custom plans as soon as an array is parameterized, by injecting SET plan_cache_mode=force_custom_plan (docs) before the query, and RESET plan_cache_mode after (while still batching for a single roundtrip).

Thanks to @laurenz and @NinoFloris for the discussions around this (if you have anything to add to the above please comment).

主要言語
C#
スター
1.8k
フォーク
268
平均マージ
2時間 35分
マージ済み PR(30日)
136

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

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

npgsql/efcore.pg のほかの issue

npgsql/efcore.pg の issue をすべて見る

似ている issue

C# の issue をもっと見る

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

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