emb_blaster wrote:

>
> I did a backup-restore, and later a diff in gstat -h of the two files (see part of it below). I saw that num of Data pages have grow after a backup-restore. O.O
> The average fill have increased as expected, but I don't understand this increase in dataPages.

Coming after the discussion of the need for an on-line compression
mechanism last week, yours is an interesting situation. Here's my
best guess. The records are short. Ignoring unused space on pages
and partially filled pages, the average record length is less than
40 bytes. That includes the record header - 13 bytes for a normal
record, 19 bytes for a fragmented header.

When a new page is created, space is reserved for back versions. The
amount of space depends on the record size. Firebird reserves space
for one fragmented record header per record on the page, so more
space is reserved for small records than for large records. As records
are modified and deleted, that space is used. My guess is that the
growth in the number of data pages is due to the reserved space.

So, it looks as if Firebird was doing a pretty good job of reusing
space in your database.

Cheers,

Ann

>
> PS.: Theres 419001 records in this table, and it is a FB2.0 database.
>
> ****before*******
> TABLEONE (160)
> Primary pointer page: 274, Index root page: 275
> Data pages: 10585, data page slots: 10585, average fill: 76%
> Fill distribution:
> 0 - 19% = 0
> 20 - 39% = 0
> 40 - 59% = 0
> 60 - 79% = 10554
> 80 - 99% = 31
>
> ***** after *****
> TABLEONE (160)
> Primary pointer page: 275, Index root page: 276
> Data pages: 11008, data page slots: 11008, average fill: 77%
> Fill distribution:
> 0 - 19% = 0
> 20 - 39% = 0
> 40 - 59% = 0
> 60 - 79% = 10702 (148)
> 80 - 99% = 306 (275)
>
>