Hello heLen,

Thank you very much for your help.

I probably need to improve my GC understanding.

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

[..]

> 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).

You mean "Select *" or "Select count(*)" ? As mentionned, I did perform a
Select count(*) with exclusive access to take care of GC (although I don't
see what there is to GC provided I only *inserted* records with exclusive
access).
I also doubled that with indices recomputes.

As mentionned things where worse after then.

However, the Select count(*) was not performed in a read-only tx as you
suggest. Could that make the difference ?

> This cuts out the randomness regarding which
> transaction will get hit with the GC.

So you mean that it could be that my Select count(*) didn't perform GC at
all ?

My SP hit the same records each time. After its first execution, shouldn't
touched records be GCed and consequently, shoudn't subsequent call to the
same SP return faster ?

> Do SET STATS from isql after you've done other cleanup then inspect the
> affected index selectivities using GSTAT.

Which I did. What should I look for exactly ?
Before and after SET STATS, my indices all have apparently good
selectivities except one which is not at all (NULLs all along). Could the
latter be a pb (index maintenance perf aside) ?

> 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.

Ok. I'll remember that. But if it were the case in my scenario, why did my
SP execution time finally returned back to normal (without rebuilding the
indices) ?

Lots of questions. Sorry.

--
Jerome