| Subject | Re: [ib-support] Update |
|---|---|
| Author | Svein Erling Tysvaer |
| Post date | 2003-01-10T10:10:47Z |
Comments below:
At 09:26 10.01.2003 +0000, you wrote:
don't index a field which only have very few values (e.g. boolean fields).
If you have such indexes, consider either dropping the index or adding the
PK at the end of the index. Indexes with low selectivity primarily affects
speed during deletes and updates, not inserts.
Also, check the plan for your queries. Too many indexes within a plan can
be as bad as no indexes at all.
didn't think a gap of 2000 should be a problem. But that may depend upon
how many records each transaction changes (to hold 1 old version of 2000
records is quite different from holding 2000 old versions of millions of
records).
of entering a new record. This window says that the transaction will be
terminated in 1 minute unless you press a button (with a more user friendly
message, of course). It is a good way to teach users how to work!
If your customer have noticed that things have slowed down recently and you
have done changes immediately prior to those changes, then those changes
are the most likely cause of his slowdown. Hope you'll find the source of
your problems.
HTH,
Set
- I support Firebird, I am a FirebirdSQL Foundation member.
- Join today at http://www.firebirdsql.org/ff/foundation
At 09:26 10.01.2003 +0000, you wrote:
>My customer complains about speed.What you should ascertain, is that each index have a high selectivity. I.e.
>I have recently created those 40 index. Before there was only 4.
>
>Could those 40 index cause the system to slow down significantly?
don't index a field which only have very few values (e.g. boolean fields).
If you have such indexes, consider either dropping the index or adding the
PK at the end of the index. Indexes with low selectivity primarily affects
speed during deletes and updates, not inserts.
Also, check the plan for your queries. Too many indexes within a plan can
be as bad as no indexes at all.
>The other thing I have in mind is, that my gab between oldestJason Chapman normally knows what he's talking about, and he wrote that he
>transaction and next transaction is somewhere around 2000.
>
>I think its one of the above that causes the slow update, but can I
>tell which is more likely to do that ?
didn't think a gap of 2000 should be a problem. But that may depend upon
how many records each transaction changes (to hold 1 old version of 2000
records is quite different from holding 2000 old versions of millions of
records).
>Besides, I think some of the clients have come to a habbit of openingWhat we do in our main application, is to pop up a window after 15 minutes
>some windows, without closing them again.
>So now I'm I have started to change my appl. to close after 10 minuts
>idle time.
of entering a new record. This window says that the transaction will be
terminated in 1 minute unless you press a button (with a more user friendly
message, of course). It is a good way to teach users how to work!
If your customer have noticed that things have slowed down recently and you
have done changes immediately prior to those changes, then those changes
are the most likely cause of his slowdown. Hope you'll find the source of
your problems.
HTH,
Set
- I support Firebird, I am a FirebirdSQL Foundation member.
- Join today at http://www.firebirdsql.org/ff/foundation