Adomas Urbanavicius wrote:

> Lester Caine wrote:
>
> You will have to supply a few more details.
> Version of OS
> Accessing method
> Some machine details
>
> Win2003 Pro Server AMD64 3000+,1GB RAM

Trying to get Linux running on mine. Response times seem reasonable on
that. Not sure what W2003 will make of the AMD64.

> Database in one file (not in *.gdb :)).Size ~ 3Gb.

Isn't there another 'recovery' feature we need to take care of? I'm
still at W2k on windows servers.

> App access via IBO, testing via EMS IBManager, DB Workbench.

Only the best then.
All three giving the same response?
I know IBO takes a while 'settling down' when you first open things up,
and does it's own caching so the delay may not all be due to FB. I'm up
to 250,000 records on some databases, and use a VIEW to provide a
current day view which is there in seconds, both via IBO and PHP. I
suppose the next question has to be - what is the SQL for the view, but
someone else may be able to help better - anyone?

>>Adomas Urbanavicius wrote:
>>
>>>Hello,
>>>We have some huge tables (~ 3.000.000, ~100.000). I have created joined
>>>view on indexes, but, anyway , when first accesing filtered VIEW there
>>>appear huge delays (something like 20-60 secs). (for ex: select from
>>>VIEW1 where mydate <'2005.01.01' )
>>>On next time with that selection there are normal filtering delays
>>>something like 1-0.5 secs.
>>>I understand, that FB caches dataset, but it would be nice to optimize
>>>that caching to maximum.
>>>As far as I understand params affecting this are
>>>DefaultDbCachePages,SortMemBlockSize ,SortMemUpperLimit , and Server type.
>>>I have tried to tune those params, but results always are more or less
>>>the same.
>>>Maybe someone faced same problem and could help out with params settings ?

--
Lester Caine
-----------------------------
L.S.Caine Electronic Services