On 5 Oct 2004 at 10:27, Dmitry Yemanov wrote:

> We have the very similar problem with "reserve" option in DPM. The engine
> reserves up to 50% of the data page space for the subsequent updates to
> preferrably place the back versions on the same page. But for every big
> table which tends to be stable we have up to 2x page I/O which is also an
> obvious bottleneck.

No, reserve is 20%. If there is any difference from average 80% fill
ratio, then it's caused by data change pattern. Engine always do its best
to keep 80% fill ratio. Take a gstat look at freshly restored database.
It's also an answer to your problem with "stable" tables. If they're
fragmented beyond 80% average fill ratio, a backup and restore should fix
it. You still would have some empty space in datapages for those tables,
but 20% is not so bad in average scenario. Well, we can introduce a table-
level no-reserve flag for really huge heavy-duty static tables that would
make 0.5% users happy, but I'd not rush for that (proposed feature for FB
4.0).

Best regards
Pavel Cisar (ICQ: 89017288)
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information