Georg Thome wrote: > thank you very much for your tips. I'm sure they would reduce > the time > for our procedure a lot. > But there are a few other questions... > We've got appr. 20 tables which are collecting measurement data from > tester maschines. If we are now running the update statistics process > this makes an exclusive lock on the specified table there. This > measurement result tables are very huge and the process takes > a lot of > time for each of them. > I don't really understand the reason for this exclusive lock. > Why is this exclusive lock needed, because the data and the > indexes are > not changed by only updating some system tables with > information about > the distribution and any physically address informations or whatever. > I don't think that the information for the optimizer has to be so > accurate that the tables has to be locked everytime and the > values are > only a snapshot for the time the procedure started. A few > moments later > after the lock is gone the data has changed anyway a lot. > In fact these locks are the main problem we have with the > whole procedure. > For the verify procedure on the other side I can understand > those locks.
Hi, after some discussion the only reason we could found for this exclusive locks was that they should guarantee that the result of a long running update statistic command could be inserted into the system table without a collison with another transaction. But we came to the conviction that it's better to live with an unsuccessful update statistic run than with a lot of lock collisions. So we will remove the exclusive locks in one of the next releases. For detailed information about this change request have a look here: http://www.sapdb.org/webpts?wptsdetail=yes&ErrorType=1&ErrorID=1128406 Kind regards, Holger SAP Labs Berlin -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
