HierarchyID Indexing/Performance

Question

Hi experts of the internet! I've got a weird issue, and I'm hoping you guys can help me out. I'm sure I'm just missing something fundamental
here, but I'm at my wits end.
Take the following scenario...
CREATE TABLE #ParentItems (
ItemID UNIQUEIDENTIFIER,
HID HIERARCHYID,
TreeID UNIQUEIDENTIFIER,
HIDLevel AS HID.GetLevel()
CREATE TABLE #ChildItems (
ItemID UNIQUEIDENTIFIER,
HID HIERARCHYID,
TreeID UNIQUEIDENTIFIER,
HIDLevel AS HID.GetLevel()
CREATE UNIQUE NONCLUSTERED INDEX PInd ON #ParentItems(TreeID, HIDLevel, HID)
CREATE UNIQUE NONCLUSTERED INDEX CInd ON #ChildItems(TreeID, HIDLevel, HID)
So two tables, the parent table has a bunch of IDs/HIDs which I know are ancestors of items in the child tables. There are multiple different
tree structures in each, hence the TreeId (all HIDs for the same tree, share the same treeID).
Assume #ParentItems and #ChildItems have 20,000+ rows in each.
The following query is reasonable fast (for what it's doing...) it takes around a second to complete.
SELECT DISTINCT LIParent.ItemID as ParentID, LIChild.ItemID as ChildID FROM #ParentItems LIParent
INNER JOIN #ChildItems LIChild ON LIChild.HID.IsDescendantOf(LIParent.HID)=1
However, this ignores the TreeID relationship as well. Now the second I add "WHERE LIParent.TreeID = LIChild.TreeID" to the query
(or add it to the join) the whole query jumps up to around 30 second execution time.
This seems like a very simple change, and I believe the index is in place... but it slows down massively.
Anyone have any ideas? Thanks in advance!

Answer 1

Can you post images  (or XML file) of the execution plans? Thanks.
BOL: "      Indexing Strategies for Hierarchical Data
There are two strategies for indexing hierarchical data:
Depth-first            
A depth-first index stores the rows in a subtree near each other. For example, all employees that report through a manager are stored near their managers' record.
In a depth-first index, all nodes in the subtree of a node are co-located. Depth-first indexes are therefore efficient for answering queries about subtrees, such as "Find all files in this folder and its subfolders".
Breadth-first            
A breadth-first stores the rows each level of the hierarchy together. For example, the records of employees who directly report to the same manager are stored near each other.
In a breadth-first index all direct children of a node are co-located. Breadth-first indexes are therefore efficient for answering queries about immediate children, such as "Find all employees who report directly to this manager".
Whether to have depth-first, breadth-first, or both, and which to make the clustering key (if any), depends on the relative importance of the above types of queries, and the relative importance of SELECT vs. DML operations. For a detailed example of indexing
strategies, see Tutorial: Using the hierarchyid Data Type."
LINK: http://technet.microsoft.com/en-us/library/bb677173.aspx
Kalman Toth Database & OLAP Architect
SELECT Video Tutorials 4 Hours
New Book / Kindle: Exam 70-461 Bootcamp: Querying Microsoft SQL Server 2012