I'd like to keep more code outside the engine. Usage analysis should be done
outside, for example, to create different index sets for different
workloads.

It is not unusual for a database to have very different workloads
Monday-Friday vrs. weekends (maintenance, data warehousing, whatever). What
can be optimal for one workload can be disastrous for another, and it takes
time for the engine to figure out it isn't just detecting odd queries.
Someone who knows what workload will be used in the next few days can apply
the most appropriate index set. No amount of coding will allow the engine to
know what queries will be run in the future!

The administration of index sets, applying them to the engine (maybe with
cron), etc., should be kept outside the engine; let the engine just perform
usage logs.

Marcelo Lopez Ruiz

----- Original Message -----
From: Ungod <ungod@...>
To: <IB-Architect@egroups.com>
Sent: Wednesday, July 19, 2000 9:58 AM
Subject: RE: [IB-Architect] smart indexing (was) new idea/proposition.


> okay, let's get this thread a proper title. another point i want to bring
up
> in this discussion is do we want to just keep hit counting on the
> columns/column-sets in the database as long as the db lives, or should we
> have a lfu/lru strategy that drops them off the end? I'd probably suggest
> here say a hitcount div age since last used strategy here, that combines
> least frequent/least recent together into a single factor. Obviously also
> having this data as say a new system table stored in the .gdb would be a
> good idea too, as the data would travel with the dataset, (obviously,
cross
> .gdb indexing is not even worth contemplating). also mentioned below is
the
> idea that this can be done outside of interbase, can someone point me in
the
> right direction? (running dangerously low on time atm.... must relax....
> must stop..... ah bugger it, i'm having too much fun).
>
> --
> Ungod (W.King)