Execution Plan

Hello,
I have a execution plan for a query where it has BOOKMARKLOOKUP operator
is that good or bad.
Thanks
chin
Not so good. It seems that the query users non clustered index and requires
BOOKMARKLOOKUP to point to the datapage in order to retrieve the data.
"chinn" <chinn@.discussions.microsoft.com> wrote in message
news:24B77FA7-6020-4072-926D-DA0A9209A97E@.microsoft.com...
> Hello,
> I have a execution plan for a query where it has BOOKMARKLOOKUP operator
> is that good or bad.
> Thanks
|||chinn wrote:
> Hello,
> I have a execution plan for a query where it has BOOKMARKLOOKUP
> operator is that good or bad.
> Thanks
Bookmark lookups are the only way to access data that resides on the
data pages when a non-clustered index is used. It happens all the time.
I don't know that I'd agree that they are necessarily bad. They are just
a necessity, but they are certainly a little slower than using clustered
indexes or covering non-clustered indexes. Not all queries can make use
of the clustered index. In those cases, you'll see bookmark lookups.
The non-clustered index contains pointers to the data. After the pointer
is retrieved, a bookmark lookup operation takes place to get the actual
data. For single row queries, this is usally not a big concern (unless
the query is run with a high call frequency). Larger result sets may
force SQL Server to do a table scan/clustered index scan if it feels
that the number of bookmark lookups is too high to warrant using the
index. And that should be monitored for performance reasons.
The thing to note is that if you can make use of a clustered index, try
and do that. In other words, if your current clustered index is not
being used effectively and changing it will help your queries run
faster, then by all means you should try it.
David G.
|||It's "Good".
you are using a non-clustered index as opposed to performing a table scan.
Better if you can get a Clustered Index Seek, but......
Greg Jackson
PDX, Oregon