At 04:19 PM 10/18/02 +0200, Pavel Cisar wrote:

>
>Because I have only a vague idea how the GC thread works, I can't say if
>this problem affects the Classic architecture, but it definitelly plagued
>the Super Server. Also, I have no clue if this could be (at least
>partially) solved just by setting the priority for sweep thread at least
>to the level of other threads, but as Firebird's get used in more busy
>environments, we need to find a solution. Actually, *any* improvement in
>GC performance would have a great impact on affected users.
>
>Any ideas ?
>

The original design was that any record touched would be
garbage collected if necessary. The downside of this
is that following a rollback of a massive update collection,
the poor reader would get nailed for the garbage collection
cost. Big deal. If the query is running in parallel with
the garbage collection, it will have approximately the same
amount of pain and suffering.

The problem is that the longer garbage collection is defered,
the greater the cost. The engine tries very hard to minimize
the size of old versions and to put them on page. Defering
garbage collection significantly increases the likelihood
that old versions will be off page, dramatically increasing
the cost.

I prefer to consider system cost when evaluating alternatives.
The original design had a significantly lower system cost,
albeit potentially unfair, than the current design.

Avoiding the garbage collection problem was a design goal for
Netfrastructure -- I was sick to death about hearing about
sweep. Netfrastructure is multi-generational in memory, not
on disk, so the problem just isn't there. Garbage collection
is done during verb and transation rollback and is virtually
free. A similar thing could be done in superserver, but never
in classic.

Jim Starkey