DRI (declarative referential integrity) and speed improvements.

Question

EDITED: See my second post--in my testing, the relevant consideration is whether the parent table has a compound primary key or a single primary key.  If the parent has a simple primary key, and there is a trusted (checked) DRI relation
with the child, and a query requests only records from the child on an inner join with the parent, then sql server (correctly) skips performing the join (shown in the execution plan).  However, if the parent has a compound primary key, then sql server
performs a useless join between parent and child.   tested on sql 2008 r2 and denali.  If anyone can get sql server NOT to perform the join with compound primary keys on the parent, let me know.
ORIGINAL POST: I'm not seeing the join behavior in the execution plan given in the link provided (namely that the optimizer does not bother performing a join to the parent tbl when a query needs information from the child side only AND
trusted DRI exists between the tables AND the columns are defined as not null).  The foreign key relation "is trusted" by Sql server ("is not trusted" is false), but the plan always picks both tables for the join although only one is needed. 
If anyone has comments on whether declarative ref integrity does produce speed improvements on certain joins, please post.  thanks.
http://dinesql.blogspot.com/2011/04/does-referential-integrity-improve.html

Answer 1

I'm running sql denali ctp3 x64 and sql 2008 r2 x64, on windows 7 sp1. I've tested it on dozens of tables, and I defy anyone to provide a counter-example (you can create ANY parent table with two ints as a composite primary key, and then a child table using
that compound as a foreign key, and create a trusted dri link between them and use the above queries I posted)--any table with a compound foreign key relation as the basis for the DRI apparently does not benefit from referential integrity between those tables
(in terms of performance). Or to be more precise, the execution plan reveals that sql server performs a costly and unnecessary join in these cases, but not when the trusted DRI relation between them is a single primary key. If anyone has seen a different result,
please let me know, since it does influence my design decisions.
fwiw, a similar behavior is true of sql server's date correlation optimization: it doesn't work if the tables are joined by a composite key, only if they are a joined by a single column:
"There must be a single-column
foreign key relationship between the tables. "
So I speculate, knowing absolutely nothing, that there must be something deep in the bowels of the engine that doesn't optimize compound key relations as well as single column ones.
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[parent](
[pId1] [int] NOT NULL,
[pId2] [int] NOT NULL,
CONSTRAINT [PK_parent] PRIMARY KEY CLUSTERED
[pId1] ASC,
[pId2] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Children](
[cId] [int] IDENTITY(1,1) NOT NULL,
[pid1] [int] NOT NULL,
[pid2] [int] NOT NULL,
CONSTRAINT [PK_Children] PRIMARY KEY CLUSTERED
[cId] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]
GO
ALTER TABLE [dbo].[Children] WITH CHECK ADD CONSTRAINT [FK_Children_TO_parent] FOREIGN KEY([pid1], [pid2])
REFERENCES [dbo].[parent] ([pId1], [pId2])
ON UPDATE CASCADE
ON DELETE CASCADE
GO
/* the dri MUST be trusted to work, but it doesn't work anyway*/
ALTER TABLE [dbo].[Children] CHECK CONSTRAINT [FK_Children_TO_parent]
GO
/* Enter data in parent and children */
select c.cId FROM dbo.Children c INNER JOIN Parent p
ON p.pId1 = c.pId1 AND p.pId2 = c.pId2;
/* Execution plan will be blind to the trusted DRI--performs the join!*/