>
> What you are seeing is not a direct dependency on the Windows cache

but

> rather the cost of loading the database schema details to
> prepare/optimize the query.
>

The cause may be the loading of the db schema details but the symptom
is that the Windows cache makes a big difference to the speed. If it
is really the loading of the db schema, it'll be more puzzling. My
test db contains just a simple one table with 5 fields and a few
indices:

CREATE TABLE DOC
(
DOC_ID Integer NOT NULL,
DOC_TYPE Integer,
DOC_SUBTYPE Integer,
DOC_DATE Date,
DOC_XML Blob sub_type 1,
CONSTRAINT PK_DOC PRIMARY KEY (DOC_ID)
);
CREATE UNIQUE DESCENDING INDEX IDX_DOC_1 ON DOC (DOC_ID);
CREATE UNIQUE INDEX IDX_DOC_2 ON DOC (DOC_TYPE,DOC_SUBTYPE,DOC_ID);
CREATE UNIQUE DESCENDING INDEX IDX_DOC_3 ON DOC
(DOC_TYPE,DOC_SUBTYPE,DOC_ID);

> - the version of FB you are using

2.1RC

> - the database header statistics (GStat)

Database header page information:
Flags 0
Checksum 12345
Generation 2944
Page size 8192
ODS version 11.0
Oldest transaction 2924
Oldest active 2925
Oldest snapshot 2925
Next transaction 2926
Bumped transaction 1
Sequence number 0
Next attachment ID 20
Implementation ID 16
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Oct 12, 2007 23:37:01
Attributes force write

> - the SQL query you were executing

select * from doc where doc_id = 1000 order by doc_id

and the plan returned is PLAN (DOC ORDER PK_DOC INDEX (PK_DOC))
showing that it's using the correct index.

>