Re: [Firebird-devel] Firebird 2.5: Performance degradation and increasing file size

[Ann W. H. <aha...@ib...>]

Alexander Peshkoff wrote:
> On Wednesday 06 January 2010 00:36:58 Ann W. Harrison wrote:
>>
>> ...  And also
>> run gstat -h while the test is running for a definitive answer
>> on whether there are old transactions around during the test,
>> not just after it has completed.
> 
> There is such data in Gary's letter later, at least gstat -h is present. Looks 
> like there is no such transaction.

Those gstat -h results were after the test, not during.  If the
test somehow starts a transaction that closes at the end of the
run, it wouldn't show up.

> 
>> ... its slightly interesting
>> that the file sizes are exactly the same for the database after
>> it's been backed up and restored and the first run.  I'd expect
>> some variation unless this is a single user test - or at least
>> a single writer test.
> 
> Provided empty database is restored once again (remember, all tables were 
> dropped), may be it can the same.

Can be, sure.  But with multiple writers, I would expect some
different in record placement or garbage collection to affect
the allocation.
> 
>> ... There are patterns of usage that defeat
>> that scheme - for example, if you always use indexed access through an
>> index that always increments, delete only the oldest records, and read
>> only the newest, the old records are never revisited, so they never go
>> away.  
> 
> Looks like here we have that case. Table is deleted (is it DELETE FROM TABLE1 
> followed by DROP TABLE1 commands?), what may cause it's data pages to be 
> revisited?

The drop table uses the rdb$pages entries for the table to find
all the pointer pages then releases the data and blob pages lists
on the pointer pages without looking at the data at all.

> 
>>
>> The sweep interval ...
> 
> Sweep interval does not make sense for classic and superclassic, only for 
> superserver. Am I wrong?

Since the sweep interval was added before superserver, I'd guess that it
works for classic.  Sweeping (as opposed to a backup or other process
that reads all records) was designed to reduce the list of transaction
states that the server (in SS) or each connection (in classic) needs
to maintain.  That list starts with the first uncommitted transaction
aka the oldest interesting.  That's why the sweep interval is determined
by the difference between the oldest interesting and next transactions.
In the mid-1980's, having one copy of that list with two bits per
transaction for each connection used significant memory.


> 
>>> Is there a way to automatically reduce the size of the database without
>>> running gbak?
>> No. The database is internally linked by page number, so it has to
>> be completely rewritten to release pages.
> 
> I suppose Gary talks here about reuse of pages from dropped table.

That won't reduce the file size, which is what that question was about.
He's seen that a sweep will cause pages to be reused.  The question is
why they aren't being reused during the test?  And, of course, whether
this is a 2.5 behavior or something they see with their vulcan hybrid
or other 2.x releases.


Best regards,


Ann