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 dotnet/efcore#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).