Commented by: @hvlad

Could you explain what you really want ?

Commented by: @dyemanov

What do you mean by "event of GC" in the cooperative GC mode? Garbage is collected when records are read by user statements. If some version for record A has just been garbage collected, it doesn't mean that any other versions will be GCed afterwards. So it's pointless to report about GC happening if record A has been already returned to the client.

I can see some sense in reporting GC while some attachment is GCing long record chains or index keys, i.e. for an extensive contiguous process. But it's usually not a common case. And it can be confusing if the reported GC activity was short in time, as the next query to the GC state may not report it anymore.

Commented by: @doychin

I also think that there is a need to report some progress information about long running GC.

There are cases where someone might erase lots of records in a table and when GC runs on next select it might take 10-15 minutes or even more if database is with FW=ON and on not very fast drive.

Commented by: @dyemanov

Please define "long running GC". Cleaning up after a batch delete means very short GC cycles intermixed with regular reads. The engine doesn't know whether the process is "long running" because it's performed in short steps with unknown number of iterations.

If you need to know about the GC activity you just need to look at the purges/expunges counts in MON$RECORD_STATS and see whether they grow. As simple as that.

Commented by: @dyemanov

I'm rejecting this ticket.