Helen,

note that Jerome got the worst results after issuing SELECT COUNT(*),
and that I got the worst results after Sweep.
Looks like the more garbage the better :-)

Ivan

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <firebird-support@yahoogroups.com>
Sent: Tuesday, May 11, 2004 3:31 PM
Subject: Re: [firebird-support] UPs and DOWNs after bulk inserts.


> 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