-
-
Notifications
You must be signed in to change notification settings - Fork 1
Avoiding SQL Server plan cache pollution with EF Core 3 and Enumerable.Contains() #2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Any reason to generate so many ORs rather than to just put the parameter placeholders in the IN parentheses? |
Just because I would not know how to do that! Do you think it makes any difference performance wise? |
this says no |
Hey @ErikEJ, Do you think it would be safe to remove the condition for checking argument length for Postgresql (Npgsql)? Good job BTW! |
Yes, looks like some source say short.MaxValue is the limit, but not sure about the ADO.NET provider - @roji ? |
Sorry, am missing some context... What exactly are we talking about here? :) |
Oh, OK. Yeah, PostgreSQL supports up to ushort.MaxValue (65535) parameters for each statement - but a batched command can have more than 65535 parameters (as long as no single statement does). What current argument length check do you have? |
Current max for SQL Server is 2048, so it can be much higher for postgress |
Yep, absolutely. |
Sorry for raising the dead here a bit, But im trying to put it into context and this seemed a better location than the EF Core issue for it (if you think otherwise, let me know and ill mirror there): You chose to update only the "bucketed" solution from divega's proposals - Is that solely because its more globally supported by the various DB vendors? Strictly in SQL Server (and Azure SQL), do you think the string_split or TVP solutions are preferable in the context of plan cache pollution? I'm specifically more worried about using |
I am actually writing a blog post about using string_split just now. This solution is provider agnostic, string_split SQL Server only. And when I wrote the code, TVF mapping was not available in EF Core, it is now, so no FromSql needed! |
Then i'll be looking forward for that article and will take another look at TVFs (which i thought not relevant in this context for some reason). Thanks! |
I just blogged: "Avoiding SQL Server plan cache pollution due to unparameterized Contains queries generated by EF Core" |
I had to use the IQueryableExtensions.In(), to support older SQL Server versions. It has the check I resorted to return Updated code of that extension method, according to that change:
|
I really like the solution proposed but can't seem to get the query below working. I also tried using String_Split solution but that defaults to nvarchar(4000) converting to varchar kills the db :) as db I am working on is using varchars var childItemFilter = List{"childItem1","childItem2"}; |
@Henery309 thanks for the kind words. I do not see any attempt to use the In extension method in the code Shared. Please share a full repro and I will have a look. Also, what does not working mean? |
Thanks for helping Erik appreciate it a lot. I have the following query which retrieves all projects that are assigned to staff members var dbcontet = new ProjectDbContext(); I tried using the extension method IN: But this fails with the following error message: |
@Henery309 I need a complete runnable repo in order to help, not code fragments |
@ErikEJ have prepared a running example: https://github.com/Henery309/EfCoreTest Using the following code: The output I get is: SELECT [p].[Id], [p].[Name] multiple selects are added to where clause I am trying to figure out how to get: SELECT [p].[Id], [p].[Name] |
@Henery309 Hmmm... This is made to solve a SQL Server specific issue with hardcoded paramters, and I see no hardcoded values in the SQL your are sharing. If you use SQLite, this may not be needed at all. I think SQL Server does not have issus with the multiple SELECTs. I am not sure which implementation if the In method you are using, but there are some suggesions for collapsing ORs in the comments in the gist. |
No description provided.
The text was updated successfully, but these errors were encountered: