Kjell Rilbe skriver:

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

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.

Can access to only small portions of a large table trigger GC on the
entire table?

I use classic server, so only cooperative mode for me at this time.

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