On Tue, 9 Mar 2004 20:01 , 'Becker, Holger' <[EMAIL PROTECTED]> sent:
>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 Yey! I think this is great news. Can you please give an example of how one would cause a 'failed update statistic run' with your new design? Also, please please please - can you detail how one could SELECT the raw information updated by 'update statistics' so that it can be UPDATE on a second server? We have 3 replications of the same database and it would be really nice to be able to cheat and copy update statistics results from server to server. Regards, Stephen Gutknecht full time traveler... currently in Phoenix Arizona USA going to Dallas, Texas soon... -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
