Thomas Steinmaurer skriver:

>> 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.

So, is there any case/config where such a long delay could be cause by
GC due to a SHORT operation on a SMALL table?

It's happened again now, just a couple of hours after the previous one.

Regards,
Kjell
--
--------------------------------------
Kjell Rilbe
DataDIA AB
E-post: kjell@...
Telefon: 08-761 06 55
Mobil: 0733-44 24 64