Hans wrote:

> The previously here posted one liner Executed
> at a scheduled or time or manual choice works just
> great. 'update rdb$indices set rdb$statistics = -1'
>
> No poll required IMO.
>
> Posted Jan 8, 10AM MST

There are some problems with external solutions, even these are this one
or a stored procedure call or an EXECUTE BLOCK construct which updates
the indexes using SET STATISTICS as core.

1. The users must know *the need* of updating statistics, and they must
know why, how and when to do it. If you look at the poll, you'll see
something very interesting results (at the time of writing):
a. 242 users voted 'indiferent' - from these 220 voted in _one_ day.
Sunday. Very odd. It seems that all the 'indiferents' gathered in that
day... but let's have good thoughts. Perhaps you can give me a reason
for this? I see a few: 1st reason: my db compared to server hardware is
too small / static or/and has very light load and it doesn't care for
me. 2nd reason: I think that I know what statistics are (I read
superficially the docs) but since I'm ok with the db speed why bother?
But the problem is that when they'll see another db which will update
the statistics (semi)automatically then they will (tend to) think that
the other db is better.
b. Only a very few users are against on this thing (6) or prefer
their custom way to do this (12) this is because...

2. Updating statistics must be done (ideally) without doing the things
slower on the server. Fortunately, this is simply to achieve because
updating the statistics is a very fast and low resource consumption
thing now. But in the future when (I hope) Fb will collect more
statistics, IMHO is needed a scheduler which will coordinate some
background tasks (like this one) taking in consideration the server load
(first) and some events (usually a value hit - in our case, simply
speaking, number of changes of an index). So, you must have a 'decision
maker' which will tell 'now is the right time to do it'. In your case
(and mine) the user is but this isn't always easy to do (due to human
and/or technical factors). For ex. you say "at a scheduled time". On a
web server with 24h traffic when should I put the scheduler to fire?

3. The passwords. In order to run the above command you must be logged
in. And this isn't quite good to be done from the main application,
because of obvious reasons (see point 2. above). Usually, there are some
scripts which run on a scheduled basis. But these contains inside the
connection string and, hence, the passwords in clear text. Also, and
such an application must have a (rather) strong encryption algorithm to
make these sensitive informations safe. Perhaps your LAN/environment is
considered 'safe' but (unfortunately) isn't always the case.

my 2c,

m. th.