Subject | Re: [ib-support] How does interbase work with default indexes an prepared queries? |
---|---|
Author | Helen Borrie |
Post date | 2003-01-02T00:24:55Z |
At 12:09 AM 2/01/2003 +0000, you wrote:
key.
Also, you should not create any indexes using CREATE INDEX, which duplicate
the indexes create for PRIMARY KEY, UNIQUE and FOREIGN KEY constraints.
efficient one, since the effectiveness of a stored plan can vary according
to factors which change over time, like the cardinality of the table and
the selectivity of indexes.
Provided you are careful about your indexes (not duplicating any, avoiding
such things as foreign keys which share columns with the primary key, not
indexing columns with low selectivity) the optimizer knows best. You can
use a client tool to monitor the plan generated each time the query is
prepared - IB_SQL, free from www.ibobjects.com has excellent monitoring tools.
Sometimes the optimizer might fail to generate the plan you think you
wanted. In that case, you can specify your own plan using the PLAN clause,
and override the optimizer.
have to prepare IB queries each time you run them. Even when you pass new
values to parameters, you don't need to (and should not) reprepare the
query. If you are not using a development environment that takes care of
it, have your application test whether the query is already prepared, each
time you run it. As with Oracle, a prepare is necessary only when your
query specification changes.
heLen
>Hi,Yes.
>
>After working in SqlServer and Oracle,
>Some concepts are mixed in my mind.
>
>In Interbase when i especify a PRIMARY Key,Is an index created
>Automatically?
>And what about the unique clause,does it create an index too.Yes. But you should not create a UNIQUE clause that duplicates the primary
key.
Also, you should not create any indexes using CREATE INDEX, which duplicate
the indexes create for PRIMARY KEY, UNIQUE and FOREIGN KEY constraints.
>Does Interbase keeps the plans for the most used Queryes.Usually it is best not to store plans, if the optimizer is creating an
efficient one, since the effectiveness of a stored plan can vary according
to factors which change over time, like the cardinality of the table and
the selectivity of indexes.
Provided you are careful about your indexes (not duplicating any, avoiding
such things as foreign keys which share columns with the primary key, not
indexing columns with low selectivity) the optimizer knows best. You can
use a client tool to monitor the plan generated each time the query is
prepared - IB_SQL, free from www.ibobjects.com has excellent monitoring tools.
Sometimes the optimizer might fail to generate the plan you think you
wanted. In that case, you can specify your own plan using the PLAN clause,
and override the optimizer.
>In Oracle preparing a query is not so relevant as it seems toAFAIK, they are very similar. Don't make the mistake of thinking that you
>be in Interbase.
have to prepare IB queries each time you run them. Even when you pass new
values to parameters, you don't need to (and should not) reprepare the
query. If you are not using a development environment that takes care of
it, have your application test whether the query is already prepared, each
time you run it. As with Oracle, a prepare is necessary only when your
query specification changes.
heLen