>>>>> On Mon, 15 Jul 2002 13:13:29 +0200, "Ivan Prenosil" <prenosil@...> said:

IP> However, when you update the same row in the same transaction
IP> for the second time (i.e. when new record version already
IP> exists), IB/FB can't simply create another record version with
IP> the same transaction id. Instead, it will update already
IP> existing new record version; but, because each command must be
IP> atomic, i.e. it must update either all (30000 rows in your
IP> case) rows or nothing, it must also be able to _undo_ all
IP> changes made by that single command (e.g. when the update
IP> command updates 29999 rows and an error occur with the last
IP> 30000th row, all previous 29999 chages must be
IP> cancelled/undone). To be able to undo any update, engine must
IP> keep previous state of the row in memory.

Sigh! So having some SPs that computes the various fields of a table
(it's a statistic, so each field comes from a summary of other tables)
is calling for long response times?

As usual, such tables have the general form (TheDay DATE,
TheKey1...TheKeyN INTEGER, Value1..ValueM DOUBLE PRECISION), and there
are, depending on `N', from 500 to 10k records for a single day. My
set of SPs, every 10 minutes of so, has to collect data from other
tables a precompute various summaries, updating and inserting new
records.

Since I'm trying very hard to squeeze out the time it takes to update
the tables, would be a better move to use a temp table to do the
calculations and then copy its content into the real table?

TIA, ciao, lele.
--
nickname: Lele Gaifax | Quando vivro' di quello che ho pensato ieri
real: Emanuele Gaifas | comincero' ad aver paura di chi mi copia.
email: lele@... | -- Fortunato Depero, 1929.