Update parameter-sensitive-plan-optimization.md

-------
cc: @thesqlsith

Author: thesqlsith

docs/relational-databases/performance/parameter-sensitive-plan-optimization.md

@@ -327,14 +327,14 @@ PSP optimization will provide audit data for the dispatcher plan statement, and
 
 Since PSP query variants are executed as a new prepared statement, the `objectid` isn't automatically exposed in the various plan cache related `sys.dm_exec_*` DMVs without shredding the ShowPlan XML and applying text pattern matching techniques (that is, additional XQuery processing). Only PSP optimization dispatcher plans currently emit the appropriate parent object ID. The `objectid` is exposed within the Query Store as Query Store allows for a more relational model than the plan cache hierarchy provides, see the Query Store system catalog view, [sys.query_store_query_variant (Transact-SQL)](../system-catalog-views/sys-query-store-query-variant.md#sysquery_store_query_variant-transact-sql) for more information. From a plan cache store perspective, PSP optimization will use the Object Plan CACHESTORE_OBJCP and the CACHESTORE_SQLCP cache stores.
 
-PSP optimization currently compiles and executes each query variant as a new prepared statement, which is one of the reasons that they query variants *lose* their association with any parent modules' `object_id` if the dispatcher plan was based on a module (that is, stored procedure, trigger, function, view, and so on). As a prepared statement, the `object_id` won't be anything that can be mapped to an object in `sys.objects` directly but is essentially a calculated value based on an internal hash of the batch text (see [Table Returned](../system-dynamic-management-views/sys-dm-exec-plan-attributes-transact-sql.md#table-returned) for more information). Query variant plans will be placed in the plan cache object store (CACHESTORE_OBJCP) while dispatcher plans are placed in the SQL Plans cache store (CACHESTORE_SQLCP). The PSP feature will, however, store the `object_id` of a query variant's parent within the ObjectID attribute that is part of the PLAN PER VALUE hint that PSP adds to the ShowPlan XML if the parent query is part of a module and not dynamic or ad-hoc sql. Aggregate performance statistics for cached procedures, functions, and triggers can continue to be used for their respective purposes. More granular execution related statistics such as those found in views similar to the `sys.dm_exec_query_stats` DMV will still contain data for query variants, however, the association between the `object_id` for query variants and objects within the `sys.objects` table won't currently align without additional processing of the ShowPlan XML for each of the query variants in which more granular runtime statistics are required. The runtime and wait statistics information for query variants can be obtained from the Query Store without additional ShowPlan XML parsing techniques if the Query Store is enabled.
+PSP optimization currently compiles and executes each query variant as a new prepared statement, which is one of the reasons that the query variants *lose* their association with any parent modules' `object_id` if the dispatcher plan was based on a module (that is, stored procedure, trigger, function, view, and so on). As a prepared statement, the `object_id` won't be anything that can be mapped to an object in `sys.objects` directly but is essentially a calculated value based on an internal hash of the batch text (see the [Table Returned](../system-dynamic-management-views/sys-dm-exec-plan-attributes-transact-sql.md#table-returned) section of the sys.dm_exec_plan_attributes DMV documentation for more information). Query variant plans will be placed in the plan cache object store (CACHESTORE_OBJCP) while dispatcher plans are placed in the SQL Plans cache store (CACHESTORE_SQLCP). The PSP feature will, however, store the `object_id` of a query variant's parent within the ObjectID attribute that is part of the PLAN PER VALUE hint that PSP adds to the ShowPlan XML if the parent query is part of a module and not dynamic or ad-hoc sql. Aggregate performance statistics for cached procedures, functions, and triggers can continue to be used for their respective purposes. More granular execution related statistics such as those found in views similar to the `sys.dm_exec_query_stats` DMV will still contain data for query variants, however, the association between the `object_id` for query variants and objects within the `sys.objects` table won't currently align without additional processing of the ShowPlan XML for each of the query variants in which more granular runtime statistics are required. The runtime and wait statistics information for query variants can be obtained from the Query Store without additional ShowPlan XML parsing techniques if the Query Store is enabled.
 
 You can influence the current skewness thresholds used by the PSP optimization feature, with one or more of the following methods:
 
 - Cardinality estimator (CE) trace flags, such as [Trace Flag 9481](../../t-sql/database-console-commands/dbcc-traceon-trace-flags-transact-sql.md#tf9481) (global, session, or query level)
 - [Database scoped configuration](../../t-sql/statements/alter-database-scoped-configuration-transact-sql.md#legacy_cardinality_estimation---on--off--primary-) options that attempt to lower the CE model in use, or influence the assumptions that the CE model makes in regards to the independence of multiple predicates. This is especially useful in cases where multi-column statistics don't exist, which affects PSP optimization's ability to evaluate the candidacy of those predicates.
 
-For more information, see the *Increased Correlation Assumption for Multiple Predicates* section of the [Optimizing your query plans with the SQL Server 2014 Cardinality Estimator](/previous-versions/dn673537(v=msdn.10)?redirectedfrom=MSDN) whitepaper. The newer CE model attempts to assume some correlation and less independence for the conjunction and disjunction of predicates. Using the legacy CE model can affect how selectivity of the predicates in a multi-column join scenario can be calculated.
+For more information, see the *Increased Correlation Assumption for Multiple Predicates* section of the [Optimizing your query plans with the SQL Server 2014 Cardinality Estimator](/previous-versions/dn673537(v=msdn.10)?redirectedfrom=MSDN) whitepaper. The newer CE model attempts to assume some correlation and less independence for the conjunction and disjunction of predicates. Using the legacy CE model can negatively affect how selectivity of the predicates in a multi-column join scenario can be calculated.
 
 ## See also