Hi,
In the graphical view of execution plan (in QA), a bookmark lookup was quite
easy to find. But in SSMS, it is displayed as a inner join. Although the
logic is the same, but in exec plan of complicated queries, it is much
easier to find a bookmark lookup when its icon is show rather than denoting
it by a loop join. Are there any solution to find out that if particular
index is not covering, even when the bookmark lookup is replaced with loop
join?
Thanks in advance,
Leila

Leila (Lei***@hotpop.com) writes:
I guess that it's just a matter of training to read the new layout of the
query plan. After all, the information is still there.

In 2000 a lookup operator did not reveal exactly what it was doing, nor the
fact that it was invoked in a loop (0, 1 or more times). The 2005
representation is actually more accurate.
The nested loops operator will invoke the inner operator (representing the
lookup activity) once per each row locator found by the outer operator
(representing the access method that returns the row locators). The inner
operator representing the lookup will show up as an RID Lookup if the table
is structured as a heap, and as a Clustered Index Seek if the table is
structured as a B-Tree (clustered).
This is a more accurate representation of what's going on behind the scenes
than the 2000 representation.

I can see what you mean in terms of having a harder time to figure out the
meaning of a nested loops that drives seek operations: are these lookups or
just a plain nested loops join?

The only thing that I can think of is to check whether both inner and outer
parts of the join belong to the same table.

Show quoteHide quote

Compairing Date Ranges with time
Full Text Setup
Trigger logic question - using If with AND and OR
Advanced T-SQL Question: Produce Backup Window Gantt Chart
assign a table to a path and filename?