Re: index

From: David BL <davidbl_at_iinet.net.au>
Date: Tue, 29 Jul 2008 02:07:47 -0700 (PDT)
Message-ID: <67fa389f-9429-4244-907c-b72e3784f423_at_m44g2000hsc.googlegroups.com>


On Jul 29, 1:18 pm, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message
>
> news:f08bba46-7bd1-443e-97fd-fe07a9ec1a3f_at_25g2000hsx.googlegroups.com...
>
> > On Jul 29, 10:45 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> > > "David BL" <davi..._at_iinet.net.au> wrote in message
> > > > Physical duplication of data can be appropriate to increase read
> > > > performance at the expense of write performance. Indeed any secondary
> > > > index is a form of redundancy that hurts write performance.
>
> > > Boosting read performance can be accomplished just as well with a
> > > covering
> > > non-clustered index as with a clustered index.
>
> > That is not always true. There could be an application involving a
> > query that uses the non-clustered index and also needs *all* the
> > additional data in the record. The additional seeks could mean the
> > read performance doesn’t meet the requirements.
>
> If the index is a /covering/ index, then there is no need for the additional
> read.

But then it won’t be a non-clustered index. Received on Tue Jul 29 2008 - 11:07:47 CEST

Original text of this message