Set Size to -1 to optimize SQL Server query plan execution

[ramonsmits]

• Resolves Higher SQL Server CPU/RAM utilization SQL dialect queries not hitting SQL query cache #873

Size needs to be set to -1

Smoketested using the SQL Outbox sample:

• Cloned Core to Core v9 and target locally created nugets from this branch.
• Modified the sample to have a text property increase in length for each message send
• Ran the sample where a message and sent a bunch of messages
• Cleared the query cache DBCC FREEPROCCACHE
• Ran the following query to observe the query cache statistics:

   SELECT
   	databases.name,
   	dm_exec_sql_text.text AS TSQL_Text,
   	dm_exec_query_stats.execution_count
   FROM sys.dm_exec_query_stats 
   CROSS APPLY sys.dm_exec_sql_text(dm_exec_query_stats.plan_handle)
   INNER JOIN sys.databases
   ON dm_exec_sql_text.dbid = databases.database_id
   WHERE databases.name<>'master'
   ORDER BY TSQL_Text

• Observed in the result that it works:

   (@MessageId nvarchar(4000),@Operations nvarchar(4000),@PersistenceVersion nvarchar(4000))  insert into [sender].[OutboxData]  (      MessageId,      Operations,      PersistenceVersion  )  values  (      @MessageId,      @Operations,      @PersistenceVersion  )
   (@MessageId nvarchar(4000),@Operations nvarchar(4000),@PersistenceVersion nvarchar(4000))  insert into [sender].[OutboxData]  (      MessageId,      Operations,      PersistenceVersion  )  values  (      @MessageId,      @Operations,      @PersistenceVersion  )
   (@MessageId nvarchar(4000),@Operations nvarchar(max) ,@PersistenceVersion nvarchar(4000))  insert into [receiver].[OutboxData]  (      MessageId,      Operations,      PersistenceVersion  )  values  (      @MessageId,      @Operations,      @PersistenceVersion  )
   (@MessageId nvarchar(4000),@Operations nvarchar(max) ,@PersistenceVersion nvarchar(4000))  insert into [receiver].[OutboxData]  (      MessageId,      Operations,      PersistenceVersion  )  values  (      @MessageId,      @Operations,      @PersistenceVersion  )

[mauroservienti]

@ramonsmits are you taking care of the smoke testing bit?

[ramonsmits]

@mauroservienti done! As this is an enhancement what do you think? Only release this for the next major or should this be backported to the current release major?

[mauroservienti]

I think it should be backported to the currently released major. That's the only release available to users, the next major is in the works but there is no ETA.

[tmasternak]

Nice improvement. Could we make the parameters lengths explicit?

[ramonsmits]

Although these last commits use the actual lengths of the schema it feels error-prone. It would require additional refactoring to really make the lengths part of a central schema to get the length information which is a major code change.

Dapper uses -1 as the default is a string unless the actually string length is less than 4000 and then uses 4000 UNLESS a explicit length was configured

• https://github.com/DapperLib/Dapper/blob/f0e61a740b0c2f5421a64aff0bdb4707ced1c46b/Dapper/DbString.cs#L21

I vote for reverting these changes revert to e0d21e0. That behavior is pretty much as dapper except that dapper sets length to -1 when its a null value. That logic doesn't make sense IMHO and we can keep the behavior at e0d21e0.

@tmasternak @mauroservienti what do you think?

[mauroservienti]

Agreed. 👍 to revert to e0d21e0