On 19 Oct 2002 at 12:17, Dmitry Yemanov wrote:

> 1) It's slow. I understand all these long-chain issues, but a feedback of
> the server should be predictable for user. Now someone can delete one
> million records quite fast, but subsequent selects may take hours to
> complete because of the GC. And that's without any noticeable load, even in
> single-user mode. It's a shock for users who worked with e.g. MSSQL before
> IB/FB.

Very true, and a reason for GC thread to exist. Actually, this beast has
two heads. First is slow GC thread that falls behind his duty, and second
is unnecessary full chain traversal in subsequent reads.

If GC thread has the same priority as other threads, the problem is in
low parallelism of work inside engine, and we can't do much until this
general problem is solved.

But we can try to slash the second head in meantime. If we can find a way
how to stop the chain traversal so already detected dead versions are not
read again, then most from performance hit of subsequent reads will go
away. A flag in row header indicating a dead version working as backstop
is the simplest and most obvious solution, but that would impose a page
write (more likely a dirty page in cache that could be GC'ed before
actual write happen, but anyway, it's not very nice idea). But finding a
solution for this second problem would also help when we find a cure for
first, as we can't expect that this cure would be a panacea.

> 2) It's unreliable. Just kill the server while a database is being GC'ed and
> most likely you'll have your database corrupted. Just a real-world example.
> Someone does a mass update/delete, then start a complex report, then wait
> 10, 20, 30 minutes - the server is 100% busy. One kills the connection - the
> server is still 100% busy. One kills the server - and get the database
> corrupted.

Also very true, although as Ann pointed out, there is some tricky code to
prevent that, it often happens if GC workload is high.

> Comments anyone? Are these unavoidable effects of the current design?

Not without a deep research about current GC implementation.

Best regards
Pavel Cisar
http://www.ibphoenix.com
For all your upto date Firebird and
InterBase information