Re: Accessing the data is kind-of slow here

Sybrand,

Thanks for your comments & sorry for my late reply.

> If you design a table to have records bigger than db_block_size, you will
> get all your records chained in multiple blocks. This will result in 2 I/Os
> for one record.

The db_block_size is currently set to 8192, which might be enough, because there is not much data in the sets. What we did is increasing the number(?) of blocks - which made the application much faster already.

> Also, without any further proof your select count(*) is executing a index
> fast full scan, your full table scan will always continue to the highwater
> mark of the table, and deleting records doesn't reset the highwater mark.

Right. My application currently just queries existing data. And that data is the result of one big import process. Thus, no data has been deleted yet.

> and all your database files on one single disk.

Right. That seems to be a bottle-neck.
If I unterstood our system correctely (I'm just an application developer...;-) we have a RAID system level 5, which should increase read-concurrency, because the files are mirrored on several disks.

Thanks for the effort: increasing the db_block_count(?) and computing the statistics made the execution speed quite acceptable.

Martin Received on Thu May 02 2002 - 14:59:10 CDT