At 03:13 PM 11/05/2004 +0200, you wrote:

>Ivan,
>
>Thanks !
>
>I am also playing with mass import SPs.
>Your mail simply describes all the oddities I am experiencing lately. Except
>that I haven't been able to establish cause to effect chains as clearly as
>you did. With a 10 Gb DB, each single maintenance op takes minutes if not
>hours. This makes it hard to clearly see the whole picture.
>
>Your mail gives me some tracks to explore but I'm getting crazy as can't
>seem to predict things. Slowdowns seem to happen when least expected. I just
>rerun my test case trying the reproduce the pb, but this time, everything
>went well...
>
>Since then, did you better your understanding of the pb ? Did you find
>workarounds to at least avoid it ?

The traditional solution is to perform SELECT * FROM THE_TABLE after you've
just done a mass insert or update. Do it in a read-only read-committed
transaction, ideally when you have exclusive access (for efficiency, but
not a requirement). This cuts out the randomness regarding which
transaction will get hit with the GC.

Do SET STATS from isql after you've done other cleanup then inspect the
affected index selectivities using GSTAT. With inserts or deletes, it might
prove useful to set some indexes inactive/active if the operation seems
likely to have affected the "geometry" of indexes significantly.

/heLen