> I have already seen that low priority sweep is useless.

I think we are talking about two different things.

I believe that "sweep" is a scan of the entire in an atomic
fashion. I prefer to have this type of database activity to
be envoked either at an interval of x, on demand or perhaps
scheduled. All of these are possible with sweep today.

I think the thread priority you are speaking of is the
"garbage collecter" thread not the sweep thread. However,
the sweep thread might support a priority setting.

In pre v6 servers the cost of garbage collection was payed
by read transactions. If an application had an unmanaged
or lenient transaction model it was easy to create hot spots
in the database. When users hit these spots when loaded
with garbage they'd see a big performance hit. Intermitant
performance hiccups.

V6 servers introduced the garbage collector thread. I believe
that as update and delete transactions leave garbage behind
in a queue, the gc thread would pac man them up thus, taking
the performance hit away from read transactions. I think
the feature potentially hides the symptoms that an application
has a lazy transaction model.

I need to look at your post.

> that describes the problem. 45 minutes to sweep 10K records
> in a single-user environment is TOO MUCH.

Eeeeek!! Did someone forget to commit?? :-)

> The main hit of setting sweep tread priority to low was to
> prevent heavy load during sweep, as I understand. Now low
> sweep priority is a head pain for DBA.

Unless v6 broke gbak and gfix you should still have the tools
to achieve what you want. I believe that the gc thread is
independent ( and low priority ) so that it yields to higher
proirity threads like gbak and gfix. Come to think of it a
gfix and gbak with low priority thread setting might be nice.

I remember the gc thread being designed to hang around and
clean stuff up as it builds up. Perhaps the thread is too
lazy and needs to have a higher priority or better design.

You might try using cron to schedule periodic sweeps and/or
backups. These operation will "sweep" the database on demand.

gbak -backup <db_name> <db_backup_name>

and

gfix -sweep <db_name>

The nice part about these options is that you can predict
potential performance hits.

--------------

The nice thing about all this is that now you can set the
thread priority and compile up your own version of InterBase
and see if your idea has wings. :-)

Markus