Dennis,
You state that the "inefficient indexes" are heavily used in
queries.
1) if you convert the indexes to a multi-column indexes are you
sure that the RBase query optimizer can use the revised indexes
in the query without revising the query?
2) Have you verified that the RBase query optimizer really uses
those indexes in processing the query? In my opinion, if the
index is "inefficient" I believe the optimizer is less likely to
be using that index.
3) Often there is a delicate balance between indexing items,
disk space used, and processing efficiency. This can be
especially inportant if the database is one that has
existed/been updated through many version of RBase. Also, If
there has been substantial changes in the database structure as
company operations have changed.
I have several databases that were created way back in version
prior to v3.1 for DOS and subsequently upgraded to the latest
and greatest. Over the years I have tried to take advantage of
improvements implemented but often I have inefficent programming
since the system is working and it would require a major rewrite
of the existing application to remove some of the inefficencies.
There is an programming principal "If it ain't broke don't fix
it".
4) Instead of a general worry about "inefficient" indexes I
would focus on specific processes that take the most
time/resources and try to improve them.
Jim Bentley
--- Dennis McGrath <[EMAIL PROTECTED]> wrote:
> I was discussing inefficient indexes with a colleague today.
> We have a table with many indexes on inefficient columns.
> It has not become an issue (at least not an obvious one) since
> we seldom delete more than one record at a time.
>
> There apparently was no way to avoid indexing these columns as
> they are used heavily in various queries.
>
> Today I had a brainstorm. I read recently that some types of
> SQL Server indexes add a hidden "uniquifier" to each table and
> include it in their indexes behind the scenes so even an index
> on a mostly null column will not cause problems.
>
> The obvious parallel in RBASE would be to change all these
> inefficient indexes I mentioned to multi column indexes with
> the table primary key as the second column in each.
> My tests indicate that this does not seem to affect
> performance negatively.
>
> My BIG concern is whether having the primary key included in
> so many multi-column indexes would cause problems in its own
> right.
>
> If it would not, it would be a sweet solution.
>
> Has anyone tried such a scheme?
>
> Any feedback, especially from Razzak, would be appreciated.
>
> Dennis McGrath
>
>
>
Jim Bentley
American Celiac Society
[EMAIL PROTECTED]
tel: 1-504-737-3293
