Thank both of you,

I will try it out.
Is there also a way to determine what index is still needed/useful for a
special query?

Andreas Mosmann

--
wenn email, dann AndreasMosmann <bei> web <punkt> de

Thank both of you,

I will try it out.
Is there also a way to determine what index is still needed/useful for a
special query?

Andreas Mosmann

--
wenn email, dann AndreasMosmann <bei> web <punkt> de

Thank both of you,

I will try it out.
Is there also a way to determine what index is still needed/useful for a
special query?

Andreas Mosmann

--
wenn email, dann AndreasMosmann <bei> web <punkt> de

On Apr 18, 2:29*am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
group.org> wrote:
I do believe that is the downside of deleting indices based on usage.
It only shows what's been used during the observation. That implies a
bad assumption that the usage is completely stable. To me, this seems
worse than just dropping an index and seeing who screams, since when
there is a problem in the future, you have to go through an entire
performance tuning workup because the linkage to the act of dropping
the index is obscured. Maybe I'm missing the concept. What about an
index that would be used when you pass some tipping point or boundary
condition or upgrade or change a session parameter?

I just don't get it. This looks like a feature capriciously useful
for poorly implemented systems.

jg
--
@home.com is bogus.
22 innings of baseball. Yikes!

On Apr 18, 2:29*am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
group.org> wrote:
I do believe that is the downside of deleting indices based on usage.
It only shows what's been used during the observation. That implies a
bad assumption that the usage is completely stable. To me, this seems
worse than just dropping an index and seeing who screams, since when
there is a problem in the future, you have to go through an entire
performance tuning workup because the linkage to the act of dropping
the index is obscured. Maybe I'm missing the concept. What about an
index that would be used when you pass some tipping point or boundary
condition or upgrade or change a session parameter?

I just don't get it. This looks like a feature capriciously useful
for poorly implemented systems.

jg
--
@home.com is bogus.
22 innings of baseball. Yikes!

On Apr 18, 2:29*am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
group.org> wrote:
I do believe that is the downside of deleting indices based on usage.
It only shows what's been used during the observation. That implies a
bad assumption that the usage is completely stable. To me, this seems
worse than just dropping an index and seeing who screams, since when
there is a problem in the future, you have to go through an entire
performance tuning workup because the linkage to the act of dropping
the index is obscured. Maybe I'm missing the concept. What about an
index that would be used when you pass some tipping point or boundary
condition or upgrade or change a session parameter?

I just don't get it. This looks like a feature capriciously useful
for poorly implemented systems.

jg
--
@home.com is bogus.
22 innings of baseball. Yikes!

On Apr 18, 2:29*am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
group.org> wrote:
I do believe that is the downside of deleting indices based on usage.
It only shows what's been used during the observation. That implies a
bad assumption that the usage is completely stable. To me, this seems
worse than just dropping an index and seeing who screams, since when
there is a problem in the future, you have to go through an entire
performance tuning workup because the linkage to the act of dropping
the index is obscured. Maybe I'm missing the concept. What about an
index that would be used when you pass some tipping point or boundary
condition or upgrade or change a session parameter?

I just don't get it. This looks like a feature capriciously useful
for poorly implemented systems.

jg
--
@home.com is bogus.
22 innings of baseball. Yikes!

joel garry (joel-garry (AT) home (DOT) com) wrote:
: On Apr 18, 2:29=A0am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
: group.org> wrote:
: > Thank both of you,
: >
: > I will try it out.
: > Is there also a way to determine what index is still needed/useful for a
: > special query?
: >
: > Andreas Mosmann
: >
: > --
: > wenn email, dann AndreasMosmann <bei> web <punkt> de

: I do believe that is the downside of deleting indices based on usage.
: It only shows what's been used during the observation. That implies a
: bad assumption that the usage is completely stable. To me, this seems
: worse than just dropping an index and seeing who screams, since when
: there is a problem in the future, you have to go through an entire
: performance tuning workup because the linkage to the act of dropping
: the index is obscured. Maybe I'm missing the concept. What about an
: index that would be used when you pass some tipping point or boundary
: condition or upgrade or change a session parameter?

You can disable an index. That way the definition exists but the index is
never used or maintained (i.e. no overhead). If you decide it is needed
you simply enable it.

"when you pass some tipping point"

If an index is enabled then presumably it will only be used when the CBO
decides it is useful for a query.

joel garry (joel-garry (AT) home (DOT) com) wrote:
: On Apr 18, 2:29=A0am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
: group.org> wrote:
: > Thank both of you,
: >
: > I will try it out.
: > Is there also a way to determine what index is still needed/useful for a
: > special query?
: >
: > Andreas Mosmann
: >
: > --
: > wenn email, dann AndreasMosmann <bei> web <punkt> de

: I do believe that is the downside of deleting indices based on usage.
: It only shows what's been used during the observation. That implies a
: bad assumption that the usage is completely stable. To me, this seems
: worse than just dropping an index and seeing who screams, since when
: there is a problem in the future, you have to go through an entire
: performance tuning workup because the linkage to the act of dropping
: the index is obscured. Maybe I'm missing the concept. What about an
: index that would be used when you pass some tipping point or boundary
: condition or upgrade or change a session parameter?

You can disable an index. That way the definition exists but the index is
never used or maintained (i.e. no overhead). If you decide it is needed
you simply enable it.

"when you pass some tipping point"

If an index is enabled then presumably it will only be used when the CBO
decides it is useful for a query.

joel garry (joel-garry (AT) home (DOT) com) wrote:
: On Apr 18, 2:29=A0am, Andreas Mosmann <mosm... (AT) expires-30-04-2008 (DOT) news-
: group.org> wrote:
: > Thank both of you,
: >
: > I will try it out.
: > Is there also a way to determine what index is still needed/useful for a
: > special query?
: >
: > Andreas Mosmann
: >
: > --
: > wenn email, dann AndreasMosmann <bei> web <punkt> de

: I do believe that is the downside of deleting indices based on usage.
: It only shows what's been used during the observation. That implies a
: bad assumption that the usage is completely stable. To me, this seems
: worse than just dropping an index and seeing who screams, since when
: there is a problem in the future, you have to go through an entire
: performance tuning workup because the linkage to the act of dropping
: the index is obscured. Maybe I'm missing the concept. What about an
: index that would be used when you pass some tipping point or boundary
: condition or upgrade or change a session parameter?

You can disable an index. That way the definition exists but the index is
never used or maintained (i.e. no overhead). If you decide it is needed
you simply enable it.

"when you pass some tipping point"

If an index is enabled then presumably it will only be used when the CBO
decides it is useful for a query.