Subject | Re: [firebird-support] Re: Transactions and cleaning up of rows after a massive deletion |
---|---|
Author | Ann Harrison |
Post date | 2011-10-25T20:50:29Z |
On Tue, Oct 25, 2011 at 1:57 PM, fernnaj <yo@...> wrote:
other threads to run.
usage, so again, the answer is, it depends. There is a garbage collect
thread which just removes old row versions, and there is co-operative
garbage collection in which each running query removes the old record
versions it finds. There's also a mode in which running queries remove the
record versions that are "convenient" and puts others on the list for the
garbage collector thread. I think "convenient" means that all the old
versions being removed are on the same page, but, hey, I'm old and easily
confused so it may mean something different.
Why, you may ask, do we have both a garbage collect thread and cooperative
garbage collection? Several reasons. One is that a garbage collect thread
doesn't work well with Classic. Another is that when Firebird SuperServer
is heavily loaded, the garbage collect thread doesn't get enough time to run
and garbage builds up, gradually to the point that it affects performance.
Fortunately, it doesn't attract rats.
look at other records.
Good luck,
Ann
[Non-text portions of this message have been removed]
>Yes, each connection gets a time-slice to run, then stops and waits for
> The last bit "will not run while the garbage is being collected" can have
> two meanings for me. One is that the insert will be blocked completely until
> the garbage collector finishes the cleaning of 1 million rows for the other
> transaction; the other is that the garbage collector will clean a bit now, a
> bit later (blocking the first query), and in between the other transactions
> (= my insert) are scheduled and performed and finished.
>
> I hope the second option is the correct one... right?
>
other threads to run.
>There are two garbage collection methods in SuperServer, and three modes of
> A side question: if you run two selects concurrently that happen to "go
> through" the same garbage, how will the garbage collection work? I assume
> that, if the answer to the other question is that the garbage collector
> cleans a bit now, a bit later, then both selects will take long and the
> garbage collector will be invoked sometimes by the first query, sometimes by
> the second, until both have a clean set to work with... is it so?
>
usage, so again, the answer is, it depends. There is a garbage collect
thread which just removes old row versions, and there is co-operative
garbage collection in which each running query removes the old record
versions it finds. There's also a mode in which running queries remove the
record versions that are "convenient" and puts others on the list for the
garbage collector thread. I think "convenient" means that all the old
versions being removed are on the same page, but, hey, I'm old and easily
confused so it may mean something different.
Why, you may ask, do we have both a garbage collect thread and cooperative
garbage collection? Several reasons. One is that a garbage collect thread
doesn't work well with Classic. Another is that when Firebird SuperServer
is heavily loaded, the garbage collect thread doesn't get enough time to run
and garbage builds up, gradually to the point that it affects performance.
Fortunately, it doesn't attract rats.
>I don't know. There may be some interaction with indexes that causes it to
> ...which leads me to the third question: would my plain "insert into ()
> values ()" query "provoke" the garbage collection?
>
look at other records.
Good luck,
Ann
[Non-text portions of this message have been removed]