Helen Borrie wrote:

> Yup. The first user to select from that table after the huge deletes cops
> the garbage collection.
>
> What you really need to do following these big deletes is to run a
> sweep. It will slow things down for a while but it avoids landing one user
> with the big cleanup. It will also be a good idea to run SET STATISTICS
> after the sweep, as well, then log out, then log in again.
>

hm, ok i just tried that .. and got some interesting results:

on the fbsd box:

running gfix -sweep just after the delete magically finishes withing
10 seconds and after that the select also finishes within 8 secs.
the gfix -sweep here also looks alot more "healthier" as it really
produces a lot of physical disk i/o .. and almost no cpu load.

great :-)

but on the linux box (unfortunately the production server)

gfix -sweep runs and runs and runs (and it looks like as it will
again be running for the mysterious 50000 secs) ... :-(

again almost no disk activity, just 100% cpu .. and ofcourse a select
in parallel (started after the gfix was started) also never returns ..


but, even if we just focus on the fbsd box ...

it does not explain why the garbage collection, initiated
by a client's select statement, takes >50000 seconds?!?
(with 100% cpu; i'd think of garbage collection as a disk i/o
bound process e.g. not constantly 100% cpu)

so i still think we must be hitting a bug or somethin ...

did you look at the stats from
my last select? don't they look a bit "strange" for such a small
database?

> Ideally, you wouldn't set out to run this kind of major housekeeping on
> regularly used tables during busy times.
>

hm, can i somehow disable that garbage-collection stuff on selects?
setting sweep intervall to "0" does not seem to make a difference
again results in a 50000 seconds "wait" on the first select ...

> ./heLen
>

thanks,
alex.