Stephen J. Friedl wrote:

>
> So, under what circumstances would I *not* want to max out the hash
> slots to 2039? The hash computation doesn't appear to be much more
> than an integer modulo, so it's not like larger moduli take longer to
> compute.

I think the problem is mostly wasting space - those values were set
in 1985, when memory was expensive and rare. As far as I know, there
are no algorithms that walk across the hash table - work lists are
all doubly linked lists.

>
>> I'd also try throttling back a bit on the size of the individual
>> caches, since every page in cache is lock.
>
> Hmmm, this is curious, and was what I was going to ask about anyway.
>
> Since (in this application) one database file (say, CL_123.gdb) could
> be open with multiple fb_inet_server processes, doesn't a larger cache
> just mean more coherency issues anyway?

Yes.

> I had done some playing with
> larger cache sizes, but since they are sadly not shared in the Classic
> server, it was not clear that this was going to help much.

Right. In classic, keeping the record set you're currently working with
plus its indexes in cache is good, but having a cache large enough that
you keep the last query's record set around is probably not worth it.

>
> Thinking about this: a larger cache would benefit when there is just
> one server process opening a file, but a smaller cache would benefit
> when there's more than one.

Within broad limits, yes. 10 pages is not enough. 100 pages might
be. 200 pages often is.

>
> And in any case, a smaller cache would leave more RAM for the
> *filesystem* buffer cache, which is properly shared and doesn't have
> those coherency issues.

Yes.

>
> I feel like a voyeur looking into the bowels of the database this way :-)

That's the nice thing about open source - you're not a voyeur, you're
a welcome visitor.


Regards,


Ann