Subject | Re: [firebird-support] optimizing query |
---|---|
Author | Svein Erling Tysvaer |
Post date | 2003-07-17T12:07:36Z |
At 18:08 17.07.2003 +0700, you wrote:
couple of possible values)! But I do know that if an index uniquely
identify the row within a table, then using other indexes as well will
inevitably slow things down. Hence, INDEX (RDB$PRIMARY29,MT_SMSC_IDX)
indicated that MT_SMSC_IDX ought to be eliminated.
Sometimes it makes sense to use more than one index, particularly if
neither of the indexes are very selective, but making a general rule? Well,
that's for the real experts to answer, I haven't got a clue what such a
rule would look like... Trial and error is the main way I've learnt about
these things, and then I've watched the firebird-support (ib-support) group
for as long as it has existed and the ibobjects group for a short while
before that.
Set
- I support Firebird, I am a FirebirdSQL Foundation member.
- Join today at http://www.firebirdsql.org/ff/foundation
>Next question: how do we know that an index is selective enough to be used inI don't know (well, except that you don't even index a field having only a
>a query plan?
couple of possible values)! But I do know that if an index uniquely
identify the row within a table, then using other indexes as well will
inevitably slow things down. Hence, INDEX (RDB$PRIMARY29,MT_SMSC_IDX)
indicated that MT_SMSC_IDX ought to be eliminated.
Sometimes it makes sense to use more than one index, particularly if
neither of the indexes are very selective, but making a general rule? Well,
that's for the real experts to answer, I haven't got a clue what such a
rule would look like... Trial and error is the main way I've learnt about
these things, and then I've watched the firebird-support (ib-support) group
for as long as it has existed and the ibobjects group for a short while
before that.
Set
- I support Firebird, I am a FirebirdSQL Foundation member.
- Join today at http://www.firebirdsql.org/ff/foundation