Bruce,

>
> > So how do you fix the problem, given that you will have to run the
> > procedure with different parameters? Increase the amount of system
> memory.
> > Get a faster disk. Increasing the page size so you don't have to do as
> > many random page reads on disk may help too.
> >
>
> Thank you Ann for explaining me this. I think I will start with
> increasieng the page size to 8 or 16 kb as Tomas suggested. However, what
> are the drawbacks of this increament? There must be some, otherwise it
> would be setup bigger from the begining.
>

There are a couple of downsides to a larger page size. First, modern disks
tend to have a 4K sector size, so larger pages are multi-sector. The
counter argument to that is that the disk system is likely to place a
larger write on desirable sectors than several smaller pages presented as
separate write operations. I'm not sure even I would understand that
sentence. What I meant is that if you present the disk system with a 16K
write on a disk with 4K sectors, it can figure out where to put the four
pieces of the page so they can be re-fetched efficiently. If you present
it with four 4K writes (containing the same information, roughly, but on
four different database pages), the disk system has no reason to put them
in places that are convenient to read together.

The other argument is that a large page size wastes space for small tables
- which is not a problem you should worry about. Disks are huge and
cheap. So is memory, at least in comparison with five years ago. Your
example suggests that Firebird runs well with a small cache of its own and
a large O/S page cache.


Good luck,

Ann


[Non-text portions of this message have been removed]