Pavel and others,

> From my POV, the GC thread is poorly designed - badly chosen
> trade off.

You are talking about disadvantages of the GC thread under heavy load, but
there're also other bad things related to the GC design and implementation:

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.

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.

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


Dmitry