Jonathan Neve wrote:

>Gary Benade wrote:
>
>
>
>>Jonathan
>>
>>When interbase runs a query it caches the read pages in memory, so
>>subsequent queries make use of this faster access method instead of reading
>>
>>
>>from the hard drive again. This means that frequently accessed data gets
>
>
>>delivered faster, which is what you are seeing.
>>
>>
>>
>>
>I see. Perhaps it's something like this. How about if I have several
>connections : will these read pages be kept in memory for all of them?
>
>

Jonathan,

If you use SuperServer, the cache is shared between connections, since
you have one thread for each connection, if you use Classic Server, then
the cache is just for that connection (i.e. not shared), CS uses one
process per connection.

You have more things that do cache besides Firebird:
1.) Operating System
2.) Hard Disk/Controllers

Try to reset your system, I think every time you run the query after the
reboot, you should get a slow response, because nothing will be on cache.

>Unfortunately, I actually have all these indices, as well as quite a few
>others. :-(
>Besides, if it were an index problem, it would be systematic wouldn't it?
>
>

You should be sure that your indexes statistcs are up to date, and the
index balanced.

To bring statistics up to date, use SET STATISTCS command
To balance the indices you should recreate then, use the ALTER INDEX
MY_INDEX INACTIVE and then ALTER INDEX MY_INDEX ACTIVE to recreate then,
not you cannot make FK's, PK's, and unique indices (used by constraints)
inactive, so the only option to rebalance those indices are with a
backup and restore cycle.

>Thanks!
>
>Jonathan Neve.
>
>

See you !

--

Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br