Subject | Re: [firebird-support] Long ad hoc delays? |
---|---|
Author | Thomas Steinmaurer |
Post date | 2011-02-04T14:05:16Z |
>> Thomas Steinmaurer skriver:I even think it works on a per-record basis removing old record
>>>> Thomas Steinmaurer skriver:
>>>>> Or garbage collection kicking in. The used garbage collection mode
>>>>> (background, cooperative, mixed) depends on the Firebird architecture
>>>>> and/or the GCPolicy parameter in firebird.conf.
>>>>
>>>> Oh, but I thought GC wouldn't do such large batches of work such as
>>>> this. I thought GC would do "a little every time" rather than "a lot but
>>>> seldom". Maybe I should read again about GC...
>>>
>>> Imagine you do a DELETE FROM on a very huge table and a SELECT COUNT(*)
>>> on that table afterwards. Depending on the garbage collection mode,
>>> garbage collection will either happen immediately in the context of the
>>> SELECT COUNT(*) or marked to be GC by a background thread.
>>
>> OK, but you envision that I issue some SQL that would visit all pages of
>> the table in question. I doubt that I do. I actually recall that the
>> delay has happened on select count(*) a very small and completely
>> different table.
>
> Correction: I'm not quite certain that I ONLY did that small select on a
> small table when the long/large delay kicked in. It's possible that I
> also had a debug session running that did something else. But I've been
> very careful to avoid full table scans on these two large tables, always
> doing selects using at least one highly selective index.
>
> I also read through
> http://www.firebirdsql.org/manual/gfix-housekeeping.html once again. It
> seems to say that GC only happens on a full table scan, e.g. select
> count(*). I thought GC happens on a page by page basis, as each
> individual page is accessed.
versions, which aren't used/needed by other transactions anymore.
> Can access to only small portions of a large table trigger GC on theI'm not sure, but I would say no.
> entire table?
I would try the trace route to see exactly what's going on in the
database statement wise.
Btw, any suspicious things in the monitoring tables at the time things
get hooked up?
--
With regards,
Thomas Steinmaurer
Upscene Productions
http://www.upscene.com
http://blog.upscene.com/thomas/
Download LogManager Series, FB TraceManager today!
Continuous Database Monitoring Solutions supporting
Firebird, InterBase, Advantage Database, MS SQL Server
and NexusDB!