Subject | Re: FB Size Limitations/Performance Questions |
---|---|
Author | Alexander V.Nevsky |
Post date | 2003-10-15T08:54:33Z |
--- In firebird-support@yahoogroups.com, "Andre du Plessis"
<andre@i...> wrote:
1. Are you sure specific record accessing slow queries is really based
on PK? Did you examined plan used by optimizer?
2. If some indices have the same first segment, FB1 optimizer use all
of them when access condition is specified on this column.
3. If table have many indices, optimizer must to analyze all of them
to choice which to use. Perhaps there is "magic" number when algorithm
of this analysis become unefficient, I think only Arno Brinkman can
answer. I hardly can imagine 50 indices on one table, in my (rather
complex) database max is 23 with system ones and 14 counting my
indices only. And I should say this is most old tables, created when I
started to study IB and SQL at all. If I had time I would re-design
this part of database and applications, at least half of this indices
are superfluos but they are used in explicitly planned queries which
are developed 8 years ago and live in five applications resident in
100 departments.
Best regards,
Alexander.
<andre@i...> wrote:
> have over 100 fields in the table, there are MANY indexes probablymore than
> 50, selecting a specific record based on the PK is really slow, so Iwas
> wondering if the problem has anything to do with too many fieldsand/or too
> many indexes.Andre
1. Are you sure specific record accessing slow queries is really based
on PK? Did you examined plan used by optimizer?
2. If some indices have the same first segment, FB1 optimizer use all
of them when access condition is specified on this column.
3. If table have many indices, optimizer must to analyze all of them
to choice which to use. Perhaps there is "magic" number when algorithm
of this analysis become unefficient, I think only Arno Brinkman can
answer. I hardly can imagine 50 indices on one table, in my (rather
complex) database max is 23 with system ones and 14 counting my
indices only. And I should say this is most old tables, created when I
started to study IB and SQL at all. If I had time I would re-design
this part of database and applications, at least half of this indices
are superfluos but they are used in explicitly planned queries which
are developed 8 years ago and live in five applications resident in
100 departments.
Best regards,
Alexander.