firebird/firebird-mirror
firebird/firebird-mirror
8
0
Fork 1
mirror of https://github.com/FirebirdSQL/firebird.git synced 2025-01-22 15:23:03 +01:00
Code Issues

Misc.

Browse Source
This commit is contained in:
robocop 2006-03-28 04:04:23 +00:00
parent 320ae0c598
commit 902671a044
1 changed files with 15 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
doc/README.garbage_collector
View File

@ -3,36 +3,36 @@ Firebird 2.0 garbage collector
----------------------------------------------------------- -----------------------------------------------------------
Engine knows about each record versions produced by update\delete statement Engine knows about each record versions produced by update\delete statement
and can remove it as soon as oldest snapshot transaction (OST) allowed this. and can remove them as soon as oldest snapshot transaction (OST) allowed this.
This is eliminate need to read pages with this versions again by user request This eliminates the need to read pages with these versions again by user request
(i.e. SELECT COUNT(*) FROM table) and avoid situation when this versions is (i.e. SELECT COUNT(*) FROM table) and avoids situation when these versions are
never reads (of course sweep always removed all unused record versions). Also never read (of course sweep always removed all unused record versions). Also
there are high probability that needed pages still reside in the buffer cache there is high probability that needed pages still reside in the buffer cache
thus there are less additional disk IO needed. thus there are less additional disk IO needed.
Between notifying garbage collector about page with unused versions and time Between notifying garbage collector about page with unused versions and time
when garbage collector will read this page new transaction can update record when garbage collector will read this page new transaction can update record
and garbage collector can't cleanup this record if this new transaction number and garbage collector can't cleanup this record if this new transaction number
is above OST or still active. In this case engine again notified garbage collector is above OST or still active. In this case engine again notifies garbage collector
with this page number and it will clean up garbage at some time later (old garbage with this page number and it will clean up garbage at some time later (old garbage
collector will "forget" about this page until user reads it again) collector will "forget" about this page until user reads it again)
Both cooperative and background garbage collection now possible. To manage it Both cooperative and background garbage collection are now possible. To manage it
introduced new configuration parameter "GCPolicy". It can be set to: new configuration parameter "GCPolicy" was introduced. It can be set to:
a) cooperative - garbage collection performed only in cooperative mode, such a) cooperative - garbage collection performed only in cooperative mode, such
as before IB6. Each user request is responsible for removing unused record as before IB6. Each user request is responsible for removing unused record
versions. This is how engine works before IB6. This is only option for versions. This is how engine works before IB6. This is only option for
Classic Server mode. Engine don't track versions produced as result of Classic Server mode. Engine doesn't track versions produced as result of
update and delete statements update and delete statements
b) background - garbage collection performed only by background thread, such b) background - garbage collection performed only by background thread, such
as in IB6 and latter. No user requests is removed unused record versions. as in IB6 and later. No user requests remove unused record versions.
Instead user request notified dedicated garbage collector thread with page Instead user request notifies dedicated garbage collector thread with page
number where unused record version detected. Also engine remember page numbers number where unused record version is detected. Also engine remembers page numbers
where update\delete statement created backversions. where update\delete statement created backversions.
c) combined - both background and cooperative garbage collection is performed. c) combined - both background and cooperative garbage collection are performed.
Default is "combined" for SuperServer. ClassicServer ignore this parameter and Default is "combined" for SuperServer. ClassicServer ignores this parameter and
always worked in "cooperative" mode always works in "cooperative" mode