Kate Turner wrote: I think people are trying to say that you should ask that question before you actually make the change. Myself, I have no idea what change you are making, but a change to the 'old' table is going to incur downtime on wikis as large as the English-language Wikipedia. Seeing as we were going to redesign the entire database for 1.5, I don't see the point in doing that. Timwi

On Sep 26, 2004, at 11:13 AM, Erik Moeller wrote: I've backed out the change until we have a better idea of the upgrade cost. Unless it's surprisingly small I'd much prefer to push it back to post-1.4 and get 1.4 wrapped up soon. (shrug) -- brion vibber (brion @ pobox.com)

On Sep 26, 2004, at 1:13 PM, Jens Frank wrote: When you come up with a better transition, we'll see. -- brion vibber (brion @ pobox.com)

On Sep 26, 2004, at 1:23 PM, Kate Turner wrote: I suppose you mean to say it's not a _good_ option. It's not a good option, but neither is spending much longer in downtime than we need to. We have an obligation to *keep things running smoothly*; this is why we've volunteered and this is why Jimmy & the foundation allow us to play on their expensive equipment which serves an increasingly high profile FOSS & open content project. What concerns me is that this was checked in with no discussion and with no estimates done of how disruptive the upgrade would be, despite this issue having been discussed before. A possible alternative which has been brought up before is to avoid changing the structure of the old table, rather pullings its non-textual data out to a separate table and continuing to use the old table (unaltered) as a store for old_text. This avoids copying around the most data and should in theory be faster. -- brion vibber (brion @ pobox.com)

Erik Moeller wrote: Personally, I'd prefer a transition without downtime such as the one I proposed before, but nobody seemed interested enough to discuss it.

On Sun, Sep 26, 2004 at 01:35:25PM -0700, Brion Vibber wrote: Quick benchmark on Diderot, using dewiki (one third the size of enwiki): INSERT INTO new_old (old_id, old_namespace, old_title, old_comment, old_user, old_user_text, old_timestamp, old_minor_edit, old_flags) SELECT old_id, old_namespace, old_title, old_comment, old_user, old_user_text, old_timestamp, old_minor_edit, old_flags FROM old; Query OK, 2498816 rows affected (24 min 52.30 sec) Table was created by create table new_old ( old_id int(8) unsigned not null primary key, old_namespace tinyint(2) unsigned, old_title varchar(255) binary, old_comment tinyblob, old_user int(5) unsigned, old_user_text varchar(255) binary, old_timestamp varchar(14) binary , old_minor_edit tinyint(1), old_flags tinyblob ); Probably the query can be done while the wiki is online and the transition requires only a short downtime to get the latest changes and to migrate to the new software release. Regards, JeLuF PS: Lies, damn lies, and benchmarks. Test setup was not representative. Ariel is performing better than diderot, but has additional workload at the same time.

Brion Vibber wrote: I had volunteered to do this, and have had a nearly-done patch on hand for a while now, but my ability to find time to code disappeared when classes started. Is there still interest in me finishing this? Ivan