Partition elimination inconsistent behavior

Question

Hello.
When we query a partitioned table and partition-aligned indexes are employed, seeks are performed in two steps: If the partition column is used as a predicate, the index is used to eliminate partitions assigned to ranges the predicate values don't fall in.
Then it proceeds to perform serial scans/seeks in any remaining partitions.
Now suppose I have a table partitioned on a varchar(10) column. Ranges are defined for values '230' and '281'. In SQL Server 2012 SP1,
partition elimination won't happen unless i explicitly convert the predicate value to varchar(10).
NOTE: I'd like to refrain from posting the scripts to generate the entire data structure because they are sensitive.
Basically the original objects are like the ones below:
CREATE TABLE TEST
(PARTITION_COLUMN VARCHAR(10),
SOME_ID INT)
GO
CREATE CLUSTERED INDEX IDX_TEST (PARTITION_COLUMN, SOME_ID) ON PARTITION_SCHEME(PARTITION_COLUMN)
GO
CREATE VIEW VW_TEST AS
SELECT SOME_ID, PARTITION_COLUMN
FROM TEST
WHERE SOME_ID = 9
GO
Partition scheme has 3 filegroups to cover the ranges '230' and '281' in the partition function. The partition function expects a varchar parameter.
CREATE PARTITION FUNCTION [RANGE_PROJETOS](varchar(10)) AS RANGE LEFT FOR VALUES (N'230', N'281')
GO
When I use a literal varchar value:
SELECT COUNT(*) FROM VW_TEST
WHERE PARTITION_COLUMN = '234'
Seek Keys[1] tell us there is no partition elimination, since its filter implies the selection of all partitions. If I later run this query, the "Actual partition count" value will be 3.
If I either use a variable or explicitly convert the literal value to varchar(10), partition elimination will be done:
However, the plan behavior is still inconsistent. The "RangePartitionNew" function is used when the literal value isn't known at compile time, which is acceptable for the query to the left, in the image above, because a variable is being used,
but not for the query to the right. What makes the latter all the more strange is the fact that it does an implicit conversion to varchar(10) even though it is already explicitly converted to the very same data type!!

Answer 1

This problem occurs even when querying the table directly instead of the view.
SELECT * FROM TB_RESULTADO
WHERE ID_PROJETO_EXTERNO = '234'
SELECT * FROM TB_RESULTADO
WHERE ID_PROJETO_EXTERNO = CONVERT(VARCHAR(10), '234')
Can you verify?  I see the expected actual partition count of 1 with the repro below under SQL 2012 SP2.  To add on to Paul' blog, simply following best practices as to parameterize queries with matching data types will avoid the issue with
auto parmeterization.
CREATE PARTITION FUNCTION [PARTITION_FUNCTION](varchar(10))
AS RANGE LEFT FOR VALUES (N'230', N'281');
CREATE PARTITION SCHEME PARTITION_SCHEME
AS PARTITION PARTITION_FUNCTION ALL TO ([PRIMARY])
CREATE TABLE TEST(
PARTITION_COLUMN VARCHAR(10),
SOME_ID INT);
GO
CREATE CLUSTERED INDEX IDX_TEST ON TEST(PARTITION_COLUMN, SOME_ID) ON PARTITION_SCHEME(PARTITION_COLUMN)
GO
CREATE VIEW VW_TEST AS
SELECT SOME_ID, PARTITION_COLUMN
FROM dbo.TEST
WHERE SOME_ID = 9
GO
SET STATISTICS IO ON
SELECT COUNT(*) FROM VW_TEST
WHERE PARTITION_COLUMN = CAST('234' AS varchar(10));
GO
Dan Guzman, SQL Server MVP, http://www.dbdelta.com
Dan,
You have to leave the literal value predicate as it is (without any conversions) to reproduce the aforementioned situation.