patternsqlMinor
QueryStore plan forcing limitations
Viewed 0 times
planlimitationsforcingquerystore
Problem
I have a
Occasionally a plan is compiled which includes very high row estimates for all index operations, such that the
I have attempted to force a good plan in QueryStore but this doesn't actually work, showing
I have ensured that there are no schema changes that could be invalidating the plan.
Looking at the execution plan, I see that the
Does this join to the FT index mean that plan-forcing is not supported?
DELETE statement running against a table with a full-text indexed column, a handful of foreign keys with cascade enabled. It looks like this:DELETE FROM dbo.STUDENTS WHERE STUDENTID=@STUDENTIDOccasionally a plan is compiled which includes very high row estimates for all index operations, such that the
DELETE takes a very long time and causes locking.I have attempted to force a good plan in QueryStore but this doesn't actually work, showing
last forced plan failure description of NO_PLAN.I have ensured that there are no schema changes that could be invalidating the plan.
Looking at the execution plan, I see that the
DELETE involves a join to a system table holding the FT index:Does this join to the FT index mean that plan-forcing is not supported?
Solution
When looking at the plan-forcing limitations one of the bullet points is:
Distributed query or full-text operations
However, this limitation does not mean that a delete should fail the plan forcing.
Consider these 4 queries, two
The only query that is failing is the 2nd one, which is using the
With the failure reason being
The plans for the two delete statements, which also show the same
This source gives more information on
Cannot execute query because plan conflicts with use of distributed
query or full-text operations
To answer the question
Does this join to the FT index mean that plan-forcing is not
supported?
My answer would be that this is not the reason as you should see the
The reason could be due to another limitation rendering the plan invalid, index changes, added foreign keys, ....
Extra tests
When adding a table and creating a foreign key with on delete cascade that references the table used in the queries above.We would expect the delete to fail since we cannot use the forced plan any longer.
As expected, we get the
Re-forcing the plans gives us salvation:
And removes the
The same is true for a table with a fulltext index that has a foreign key (with on delete cascade) that references the main table where the delete query is running on.
Regarding the high / low estimates
If the delete is not executed that much, adding
Posting a different question with the query plan might bring up a different workaround / solution.
Distributed query or full-text operations
However, this limitation does not mean that a delete should fail the plan forcing.
Consider these 4 queries, two
SELECT statements and two DELETE statements on a table with a fulltext index on the val column:SELECT *
FROM dbo.fulltextindexed;
SELECT val
FROM dbo.fulltextindexed
WHERE CONTAINS(val, N'WOW');
DELETE top(1)
FROM dbo.fulltextindexed;
DELETE top(1)
FROM dbo.fulltextindexed
WHERE id -1;The only query that is failing is the 2nd one, which is using the
CONTAINS statement:With the failure reason being
DQ_NO_FORCING_SUPPORTED.The plans for the two delete statements, which also show the same
clustered index merge operators get forced:This source gives more information on
DQ_NO_FORCING_SUPPORTED:Cannot execute query because plan conflicts with use of distributed
query or full-text operations
To answer the question
Does this join to the FT index mean that plan-forcing is not
supported?
My answer would be that this is not the reason as you should see the
DQ_NO_FORCING_SUPPORTED instead of the NO_PLAN error. The reason could be due to another limitation rendering the plan invalid, index changes, added foreign keys, ....
Extra tests
When adding a table and creating a foreign key with on delete cascade that references the table used in the queries above.We would expect the delete to fail since we cannot use the forced plan any longer.
CREATE TABLE dbo.fulltexreference(id int identity(1,1) primary key not null, t1id int, val varchar(max));
ALTER TABLE dbo.fulltexreference add constraint FK_test foreign key(t1id) REFERENCES dbo.fulltextindexed(id) ON DELETE CASCADE;As expected, we get the
NO_PLAN on the two delete statementsRe-forcing the plans gives us salvation:
And removes the
NO_PLAN issueThe same is true for a table with a fulltext index that has a foreign key (with on delete cascade) that references the main table where the delete query is running on.
Regarding the high / low estimates
If the delete is not executed that much, adding
OPTION(RECOMPILE) could help with the high row estimates as this can give you a better estimation due to the optimizer 'seeing' the variable at runtime. Posting a different question with the query plan might bring up a different workaround / solution.
Code Snippets
SELECT *
FROM dbo.fulltextindexed;
SELECT val
FROM dbo.fulltextindexed
WHERE CONTAINS(val, N'WOW');
DELETE top(1)
FROM dbo.fulltextindexed;
DELETE top(1)
FROM dbo.fulltextindexed
WHERE id <500 and id > -1;CREATE TABLE dbo.fulltexreference(id int identity(1,1) primary key not null, t1id int, val varchar(max));
ALTER TABLE dbo.fulltexreference add constraint FK_test foreign key(t1id) REFERENCES dbo.fulltextindexed(id) ON DELETE CASCADE;Context
StackExchange Database Administrators Q#234020, answer score: 5
Revisions (0)
No revisions yet.