> > I don't want to argue whether fragmentation will cause or not
> performance
> > issues because it definitely will and the larger the database the
> > bigger the penalty.
>
> Alex,
>
> I think you are wasting your time. Firebird works with pages and could
> not care less as to how fragmented the database file is. It doesn't
> even care if it is in 1 file or 10. If you observed any benefit, it
> would have been due to the removal of garbage and rebuilding of the index.

but Adam, imagine the DB page size equals the HD cluster size.
It's not hard to imagine that after many database operations, the clusters
(i.e. pages) are scattered over a HD, and defragmenation would tend to put
this clusters back in a contiguous block on the HD.
It's just that Alex probably perceives that defrag programs have some kind
of inside knowledge of where the DB pages should go, and they don't. A
Defrag program will just bunble the clusters back into a contiguous block,
unfortuntately the pages could be just as scattered over the HD as they were
originally. I can even imagine that the scatter could end up worse than
before.
I'm not even sure (I recall Ann Harrison saying something along these lines)
that GBAK will put all the DB pages back in some kind of natural table order
(which would be no great advantage either as I understand).
Alan

>
> If however you are convinced you can see the difference, defragment
> your hard drive, install your database and create a temporary table.
> Fill the temporary table with more data than your database will ever
> hold. Drop the temporary table and sweep. Firebird should then reuse
> the empty pages rather than requesting more from the OS, and this file
> should not be affected by fragmentation.
>
> Adam