openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From janI <>
Subject Re: [call for review] wiki maintenance
Date Thu, 29 Nov 2012 18:48:44 GMT
On 29 November 2012 19:36, TJ Frazier <> wrote:

> On 11/29/2012 13:19, janI wrote:
>> Thanks I did not know that LEFT JOIN and JOIN has different speeds on
>> inodb
>> tables. I made the fast fix, and split xmaint_uids into smaller tables,
>> and
>> is running now.
>> BUT I am dead nervous of deleting wrong data !! so the review in general
>> would be nice.
>> I have also decided to post the user list here, to give people a chance to
>> shout and get removed from the list. There are very little margin for
>> errors on our database, and I would not like to cause problems (I think I
>> already have used this years allowance).
>> Thanks for your suggestions, I will implement a couple of your ideas
>> before
>> I release the final script.
>> Jan.
>>  Quick question: How do you expect anyone to review >30K account names? I
> suggest to go ahead and delete them. --/tj/

Well ctrl-F would be one way, check your own name and maybe also your

The difference is, that all users have the possibility to check, and if
they dont they should not complain and in my short life on this list I have
learned (at least) one is better to ask. In most all other
projects where I have participated, you would be right.


>> On 29 November 2012 19:09, Andrea Pescetti <> wrote:
>>  On 29/11/2012 janI wrote:
>>>  ooo-wiki VM is so weak (compared to my notebook) that a lot of my
>>>> "special"
>>>> select/join statements timed out...and the just because I have a simple
>>>> where clause "where user_id in (select user_id from wiki_maint_uids)"
>>> I only had a quick look yesterday and I cannot check now, but there were
>>> several possible speed improvements, including using a simple JOIN
>>> instead
>>> if a LEFT JOIN and then discarding NULL matches, introducing a primary
>>> key
>>> or an index in the wiki_maint_uids table and using update on joins
>>> instead
>>> of subqueries. I didn't test any of these, and I didn't see the database,
>>> so don't trust the lines above too much! They are just semi-random
>>> thoughts
>>> based on the code I saw yesterday, and it could turn out that these
>>> changes
>>> slow down the queries instead of improving them.
>>> Regards,
>>>    Andrea.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message