Le 24 août 2010 à 13:26, Daniel Rail a écrit :

> So, just to add to Ivan's observation, it's also possible that the
> number of pages might also be configured within the database itself,
> which "gstat -h" can help to pinpoint where this 4096 pages is
> configured.

Indeed.
This is what I suspected (and verified since), but I don't know if that second post by me flew through the mail system because I never got the echo from the list. Here is a duplicate. (I have one comment, then, below).

> Le 23 août 2010 à 20:30, "Ivan Prenosil" <Ivan.Prenosil@...> a écrit :
>
>> My copy of Firebird-2.5.0.26054-0_Win32_RC3.zip without any modifications to conf
>> behaves as expected - it allocates either 75 pages, or the number specified
>> during attach, and the value is confirmed by isc_database_info().
>
> Same binary here.
>
>> Perhaps the application/components you are using does the "favor"
>> and supply 4096 value without asking to do so ?
>
> I'm the component author :). No auto supply of such a default anywhere. But I found something.
>
> What should be the real net effect of having once called the service interface with isc_spb_prp_page_buffers in the past (and probably set it to 4096 pages, some day)?
>
> SuperServer do obey that setting, stored in the database.
> Wouldn't SuperClassic obey that too?
> Isn't that an error for SuperClassic to obey that setting?

I now understand that it looks to be the documented way (well sort of) that all three architectures use the configured cache size stored inside the database file (unless it is set to zero). Though, isn't this a bit counter-intuitive for Classic and now SuperClassic to obey that global cache size, with precedence on any other setting (firebird.conf, attachment-time dpb setting)? I'd love to change slightly the wording in the firebird.conf file, to document there the precedence that property set inside the database file has over all other settings. Maybe it can save some minutes for somebody else. :)

Best regards,
—
Olivier Mascia