gstat -r output:

pre backup/restore
Primary pointer page: 636, Index root page: 637
Average record length: 125.93, total records: 129599
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 1441, data page slots: 1849, average fill: 98%
Fill distribution:
0 - 19% = 1
20 - 39% = 4
40 - 59% = 0
60 - 79% = 2
80 - 99% = 1434

post backup/restore
Primary pointer page: 635, Index root page: 636
Average record length: 133.93, total records: 129599
Average version length: 0.00, total versions: 0, max versions: 0
Data pages: 1211, data page slots: 1211, average fill: 99%
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 0
60 - 79% = 1
80 - 99% = 1210

I obviously expect some improvement from backup/restore but 15x seems more
than can be accounted for

On 30 July 2013 10:15, Nick Upson <nu@...> wrote:

> Hi Mark,
>
> I believe I've eliminated fragmentation as the gstat output for the tables
> is almost identical, no other connections to the database exist, so its not
> an OIT issue
>
>
> On 30 July 2013 10:07, Mark Rotteveel <mark@...> wrote:
>
>> **
>>
>>
>> On Tue, 30 Jul 2013 09:37:09 +0100, Nick Upson <nu@...> wrote:
>> > Hi Thomas,
>> >
>> > I am running classic firebird 2.1, but I don't think its GC as I ran
>> both a
>> > sweep and a backup and still got the same, longer, time
>>
>> It can be a different number of issues: less fragmentation, no (or
>> shorter) record version chains, large difference between OIT and the
>> current transaction number in the database before backup causing
>> continuous
>> sweeps or something like that.
>>
>> Mark
>>
>>
>>
>
>
>
> --
> Nick Upson, Telensa Ltd
>



--
Nick Upson, Telensa Ltd


[Non-text portions of this message have been removed]