[fixed] Deleting Thread exceeds max execution time

[mike999]

When I delete a single thread as the administrator, I get the following error:

Fatal error: Maximum execution time exceeded in ./admin/functions.php on line 1848

(We're using the newest VBulletin on dual P800's)

[tubedogg]

A single thread times out?

*sigh*

This is a bug no matter what they say! :D

[Fusion]

King Tube has spoken? ;)

[tubedogg]

Sumthin like that. ;)

I thought maybe it was OK when mass-pruning threads but if one thread times it out there's something wrong.

[Fusion]

Yup. altho that one's gonna be tricky to nail. Works fine on my local board, that's running on an icky P200 with 64mb RAM and Win2000Pro. Should be thrashy enough force most any performance-related bug. Didn't even hickup..

[mike999]

We tried resetting the php.ini execution time from 30 seconds to 60 seconds, (then restarting Apache) but we're still getting the same message.

You can give it a try at http://forum.doityourself.com

If we delete just a single post, rather than an entire thread, we get a similar message:
Fatal error: Maximum execution time exceeded in ./admin/functions.php on line 1848

[John]

This will have something to do with your search index and removing the thread's entries from there. I will look at it, and try and come up with a fix, but I am not sure there is a huge amout I can do.

John

[risestar]

I an having a simular problem since upgrading to 2.20, cannot delete threads, the page times out. Tried raising the max execution time, still no go

[NYI Fan]

I'm having similar issues mass pruning. My host has tried setting the memory to 16M as well as up the time out to 180 for me, and I attempted it again at low server load time, and i still get the errors.

I never tried a mass prune in 2.0.1 or 2.0.3, so I can't say it worked until I updated to 2.2.0

my thread on this, and Eva's valient efforts to help:
http://www.vbulletin.com/forum/showthread.php?s=&threadid=33740&perpage=15&pagenumber=1

I would really like to get rid of my ghost entries - any other suggestions would be great!

Thanks!

[eva2000]

probably explains it if 1 thread being pruned timesout

[Chen]

I'd like to add that mass pruning threads is unusable.
You can only delete about 15-20 threads per run.

I (and another person) had to write our own scripts to do a mass deletion.
Using the deletethread() function isn't the "best" idea. It's taking the easy way.

Just MHO. :)

[risestar]

Was there a change in the way that vbulletin deletes posts and threads? I am wondering why I was able to before upgrading to 2.20.

I have a fairly large forum with a lot of posts and threads, not sure if that could have something to do with it or not

[Chen]

No, nothing was changed in that area.

[risestar]

Possibly then there is a breaking point where some functions of vbulletin don't work once ones db gets too large :(

[Fusion]

Originally posted by FireFly
I'd like to add that mass pruning threads is unusable.
You can only delete about 15-20 threads per run.

I (and another person) had to write our own scripts to do a mass deletion.
Using the deletethread() function isn't the "best" idea. It's taking the easy way.

Just MHO. :) Firefly, why not take this opportunity to influence Jelsoft so they re-do these parts, and implement proper mass-pruning then? Perhaps use what you guys already had to make as a base?

[Chen]

That other person is tubedogg, btw.
And he agrees with me (I think ;)) about this issue.

Don't worry, I'm sure this will be fixed next version (at least the mass pruning thing).
(I hope someone will fix it so I don't look stupid ;))

[eva2000]

Originally posted by FireFly
That other person is tubedogg, btw.
And he agrees with me (I think ;)) about this issue.

Don't worry, I'm sure this will be fixed next version (at least the mass pruning thing).
(I hope someone will fix it so I don't look stupid ;)) or could you do a 1 php file add on for now which can interface with the forum database and do the pruning for now without the need for vB owners to hack the original file ???

[Fusion]

Originally posted by FireFly
That other person is tubedogg, btw.
And he agrees with me (I think ;)) about this issue.

Don't worry, I'm sure this will be fixed next version (at least the mass pruning thing).
(I hope someone will fix it so I don't look stupid ;)) A lil' lesson in humility can't hurt, can it? :p

[Chen]

Originally posted by Fusion
A lil' lesson in humility can't hurt, can it? :p
:confused:

[Fusion]

Originally posted by FireFly

:confused: "...
(I hope someone will fix it so I don't look stupid )"

I think that concludes the lesson for today. ;)

[ChrisFrez]

I'm getting the same error message when trying to do a Mass Prune:

Fatal error: Maximum execution time of 30 seconds exceeded in /home/webmaster/www/forums/admin/functions.php on line 1849

:(

[Hotte]

There are 2 problems when deleting a thread:
first the searchindex. the query for deleting the entrys runs through the whole searchindex-table.
second the attachment-check. the query runs through the whole post-table.
When you these two tables are "big", the max execution time is reaching. I´ve commented these two out. There was no other way. I wasn´t able to delete a single thread.

[risestar]

What exactly did you comment out and where to restore your deletion ability hotte?

[TommyBALL]

I've done a little "research" into this problem, and have also come to the conclusion that it is the "DELETE FROM searchindex WHERE postid=$postid"

Since the postid column does not have an index, the DB will have to go through the entire searchindex table for each deletion.

I solved this problem by adding an index.ALTER TABLE searchindex ADD INDEX postidThe downside to this is that it will take up more diskspace. But the speedincrease is humongus!

Now I can even do a selective delete of posts from a thread, without "killing" my server :D. Saving edited posts is also MUCH faster.

Regards
- TommyBALL

[freaky]

I was able to do mass prune/delete perfectly fine in 2.0.3 and wiped out 20k/30k threads in a few hours time....the page used to time out but when I checked back in 2/3 hours, they WERE gettin deleted.

Since upgrade to 2.2.0, i cant delete threds anymore, it gives that max execution timeout error no matter what I do.

My database has grown from 375MB to 980MB because I have all these old threads I cant delete. Usually I keep the number of posts around 100k, I have 300k now since I cant delete.

A few things to remember is that I have 26k members and get 11k/12k posts a day...my attachment table and search index is probably pretty big, if that somehow plays a part.

So, is there a fix for this? Things were just fine in 2.0.3

[fury]

On my board, I can kill off about 60 threads per run (in both 2.0.3 and 2.2.0), with most of them averaging 10-15 posts and having usually two or three 10-30k attachments per 5 threads

I am unsure of the exact specs, but I do know that it is a dual pentium 3 running Redhat Linux 6.2, and I think 512k of ram

That is astonishing that it is timing out when you are trying to delete just one thread! :eek:

[risestar]

I have an index in the postid column but that still does not solve the problem.

I think possibly the problem is the size

Database: forum
Tables: 42
Data: 476.6 MB
Indexes: 301.7 MB
Total: 778.3 MB


For some reason the upgrade to 2.20 has lost a lot of efficency in searching and removing threads and posts from the database as I was able to delete with no problem with 2.0.3

[TommyBALL]

My searchindex table definition now looks like this...CREATE TABLE searchindex (
wordid int(10) unsigned NOT NULL default '0',
postid int(10) unsigned NOT NULL default '0',
intitle smallint(5) unsigned NOT NULL default '0',
UNIQUE KEY wordid (wordid,postid),
KEY postid (postid)
)And as mentioned earlier, deleting/editing posts is now blistering fast compared to before the extra KEY postid (postid)
Hope this makes my previous post in this tread somewhat clearer :confused: :)

risestar: The reason for the slowdown in 2.2.x is because it now deletes the searchindex entries too. In 2.0.3, it didn't. You had to run the Rebuild search index procedure after deleting more than a single post to make the search function up to date again. But the "missing" postid index seems to "kill" quite a few vB's with any sizeable searchindex table...

I would appreaciate it if some of the moderators or developers would comment om my "ravings" ;)

Regards
- TommyBALL

[Hotte]

Originally posted by risestar
What exactly did you comment out and where to restore your deletion ability hotte?

in admin/functions.php

there in function deletethread
the "checkattachment" - part

checkattachments=$DB_site->query......
while ($omitattach....
...
}

add /* before checkattachments and */ after the } from while

also add an # before the
$DB_site->query("DELETE FROM searchindex....

[risestar]

Thanks Tommyball and Hotte, I followed both of your suggestions and am now able to easily delete threads from the forum and the search index has sped up a bit as well. :)

[Afterburner]

we made this changes and it works:

look in the function.php:


// make sure you don't remove attachments that are already in use!
$checkattachments=$DB_site->query("SELECT attachmentid FROM post WHERE attachmentid IN ($attachmentids"."0) AND threadid<>'$threadid'");
$omitattachmentids="";
while ($omitattach=$DB_site->fetch_array($checkattachments)) {
$omitattachmentids.=$omitattach['attachmentid'];
}



and replace it with:


// make sure you don't remove attachments that are already in use!
if ($post[attachmentid]==1) {
$checkattachments=$DB_site->query("SELECT attachmentid FROM post WHERE attachmentid IN ($attachmentids"."0) AND threadid<>'$threadid'");
$omitattachmentids="";
while ($omitattach=$DB_site->fetch_array($checkattachments)) {
$omitattachmentids.=$omitattach['attachmentid'];
}
}

[powerforen.de]

Work very fine! ;)

[Omero]

We have this problem as well... it hits us VERY much, i cant moderate the forum coz i cant delete any posts.

I think this is a serious issue (hit any forum with 2.2.X and a DB larger than 200-300 mb... our is around 1 gb) and should be addressed shortly, maybe a quick fix, like 2.2.2?

Would like to hear some official answer here, thx. I need something quick, either by manually editing phps (which i dislike because of problems then updating vBB with new versions, etc...) or by applying a possible 2.2.2 version.

Thanks for your support guys ^_^

[risestar]

omero, hacking the php in the manner explained in this thread fixes the problem. Since its a non-essential problem as the majority of users have smaller db's its not likely to be resolved until the next version which may be a little bit.

[Omero]

Could someone explain me a bit WHAT exactly do i have to do, which steps, which order? Im no mysql expert, but I know how to run queries and how to edit php filez ;)

I'd just like to see something like

1) Open XXX.php and edit it like this

2) Then Run this query

3) Open YYY.php and add that

, etc...

Cause this thread is a little bit confusing and i dont know what do i have to do exactly.

Thanks in advance, i think this is useful to a large number of ppl anyway.

[Omero]

Let's see if I got it right:

1) First i have to run the query suggested by TommyBALL in order to add a post id field to searchindex, so that he doesnt have to go thru ALL search index table (mine is REALLY large, 11 millions of records ;) )

Query: ALTER TABLE searchindex ADD INDEX postid

Do i have to rebuild search index after that or not? I didnt get this.

2) I have to modify the function.php in the way suggested by Afterburner.

That's it, just that? No other thing needed? How long will the query take with a 11 mil records SI ? :D

[Lapo Luchini]

1) of course not, it's just an addictional index to speed up search based on postid (which was never used before)

2) I haven't got for what it serves: how can an attachement be still needed if we're deleting the thread?

[Omero]

The second is needed just because the function go and search for a possible attachment to delete, matching the post that is going to be deleted... this is done EVEN IF POST HAS NO ATTACHMENT (the fix modify this, first check if there is an attachment, before searching! ;) ).

This unneeded search may be a lot slow, especially with big attach tables and given the fact that mysql handles very poorly tables with big objects, and this slowness is added to already slow search in searchindex ;)

[risestar]

Adding the postid to the search index, however the real problem is the query that searches thru the searchindex for the post when deleting them. I used the solution that hotte proposed and commented the sections out and it works fine.

[tubedogg]

The problem with not deleting from searchindex is you will probably end up with phantom search results. Also this will mean your searchindex will never get smaller, only larger, and so this problem will never go away. At least if you delete from it, it will get smaller, or at least not grow as fast as it would if you never delete from it.

[freaky]

I upped my max execution time to 216700 or 6 hours....all is well now...deleting threads no prob

[risestar]

Tubbdogg, the fix by afterburner still allows for deletion out of the search index correct?

[tubedogg]

Correct.

[rylin]

another possible problem when dealing with scripts that take a long time to execure is timeouts to the http server (unless the php timeout comes first, that is), which is quite easily fixed..

i'm currently writing a few import scripts, but after the standard IE timeout (120 secs?), the connection was lost and script execution stopped.. to fix it, i just added sort of a progressbar, printing a "." every 1000 queries, making sure the connection was kept alive.

[Omero]

I've tried out the query to add index to searchindex table and then the deleting became really fast (didnt have to go thru my 11 millions record table :P) ;)

Then also added the check in function.php for attachment, and i think that speeded it up a bit more, but really couldnt check that well, cause it was already fast ^_^

Side effect: my searchindex table grew a lot, now i have a over 2 gigs total DB ;)

In the end: solved the problem, thank you guys ^_^

PS I think this SHOULD be included in 2.2.2 version, both the mysql alter query to add the index to SI table and the function.php fix... deleting thread is a MAJOR feature, very much needed by anyone, and this "bug" kill that feature with DBs larger than N, where N is not that big amount... average size DBs already got hit by this rpoblem, so i really suggest Jelsoft to look into it ^_^

[risestar]

Yes, it should someone should let them know about it in the bugs forum or something


Originally posted by Omero

PS I think this SHOULD be included in 2.2.2 version, both the mysql alter query to add the index to SI table and the function.php fix... deleting thread is a MAJOR feature, very much needed by anyone, and this "bug" kill that feature with DBs larger than N, where N is not that big amount... average size DBs already got hit by this rpoblem, so i really suggest Jelsoft to look into it ^_^

[rylin]

hmm.. trying to run the query..
You have an error in your SQL syntax near '' at line 1

ideas? :(
it's exactly like described above.. also tried doing it in phpmyadmin, which times out..

mysql 3.23.43

[Sire]

I went through all these threads and saw some temporary fixes but not exactly an ideal way to handle this performance issue.

I don't want phantom search results if I comment out any code normally would be deleting postid's in the searchresults. The searchtable postid index already exists in my version. ( vb 2.2.0 ).

I tried adding the post attachment check which seems like a great idea, but it gave me a parse error. I'm not sure if this is because of APC or not.

A parse error in functions.php on this line, line 1846
if($post[attachmentid]==1) {

[Toibs]

... So the solution to this problem is???

Sorry i've just found i have this too :(

Fatal error: Maximum execution time of 30 seconds exceeded in functions.php on line 1849


Just read thro all of the above, and it doesn't really mean a huge amount to me, as there are that many "this works" and "this bit doesn't work" in there :)

Simple questions

- is this fixed yet?
- what is the fix if it has?
- if it hasn't are the jelsoft guys working on this?

Thanks chaps and chappesses :)

Paul

[TommyBALL]

Tobis: Adding the missing index will most probably solve your problem...
http://vbulletin.com/forum/showthread.php?s=&postid=209381#post209381
http://vbulletin.com/forum/showthread.php?s=&postid=209569#post209569

If you need more assistance, your'e welcome to PM me.

Regards
- TommyBALL

[Joshua Clinard]

Can we get a developer to answer this? Is it fiexed yet? If so, can they please package all the recent fixes, about 8 I think, and release a minor upgrade, 2.2.3? Please?

[freaky]

I upgarded to php 4.1.0 and max execution timeouts went away....give it a shot

:)

[TommyBALL]

Fazle: It would be more helpfult if you came with input that's reltated to the problem discussed in this thread.

The problem discussed here is related to the MySQL database-server "overloading" becase it's asked to do a lot of extra work when "cleaning up" after deleting threads/posts.

When you did a deletion of the affected type before vB 2.2.0, vB didn't clean up the searchindex (and the attachments?) related to the deleted posts. You then had to do a manual reindex to fix the searchindex. In 2.2.0/2.2.1 it cleans up immdeiately. But the "missing" index will make MySQL "overload" with immensely inneficient sequential searches through the ENTIRE searchindex table for each word deleted (and there are quite a few words in each post).

It takes so long to do these deletes that PHP is starved while waiting "forever" for MySQL to finish. This leads to the scripts timing out.

With the extra index, MySQL will only use a fraction of the time when searching for, and deleting, the words related to the deleted posts.

Upgrading PHP will NOT affect this problem since the problem is in the database, not in the PHP scripts.

Regards
- TommyBALL

[roy7]

In our case we had added this index a long time ago, but still deletion took ages. It was the attachment stuff. Man, did you know even without an attachment it was requesting 750K rows from our post table? That's just scary.

Query: SELECT attachmentid FROM post WHERE attachmentid IN (0,0) AND threadid<>'102279'
Time before: 0.076480031013489
Time after: 10.008273005486

Query: UPDATE user SET posts=posts-1 WHERE userid='19727'
Time before: 60.214689970016
Time after: 60.216117978096

From an explain on the thread deletion. Aiiieee...

-Jonathan

[roy7]

Also, instead of

$omitattachmentids.=$omitattach['attachmentid'];

wouldn't something like

$omitattachmentids[$omitattach['attachmentid']] = 1;

be more efficient? Then you can get the 'unique' ids to ignore from the keys in the omitattachmentids array, instead of '0' appended to the list 750K times?

-Jonathan

[roy7]

Adding the patch on page 3 dropped our time to delete a post from 60 seconds to under 2 seconds. Much better.

As for speeding up deletion of posts with attachments, I think we'd need to use the idea I put in the previous reply with a bit of new code to use it properly, or if you don't mind offloadnig the 'unique' work to MySQL, add a DISTINCT to the query. ie:

SELECT DISTINCT attachmentid FROM post WHERE...

All it needs to know is if other threads use an attachment or not. This would, in our case, return one row with '0' instead of 750K rows with '0'. Bypassing the 50 seconds of php building that giant array and so on.

So to conclude, the page 3 patch dropped us from 60 seconds to 1-2 seconds for posts without attachments, and DISTINCT would speed up deleting a post with an attachment significantly as well. (Maybe 60 seconds to 10-20 seconds.)

The page 3 patch really must go into the next vbulletin release, IMO.

-Jonathan

[Joshua Clinard]

Can we seriously get a developer's comment on this?

[David Bott]

I hope so...for Jonathan and I worked on this issue for a number of days and did quite a bit of testing with different indexes. As you can see, our forum is quite large...thus the "patch" on page three was a god sent.

WE NEED AN OFFICIAL 2.2.2 release with all the patches please!


BTW....I wish to publicly thank Jonathan for all his effort with our forum and VB/MySQL.

[tubedogg]

Originally posted by David Bott
WE NEED AN OFFICIAL 2.2.2 release with all the patches please!There are currently no plans to release any more versions in the 2.x line. This may change but ATM there is no release planned.

[David Bott]

Originally posted by tubedogg
There are currently no plans to release any more versions in the 2.x line. This may change but ATM there is no release planned.

WOW....With the number of bugs that have been reported and fixed in 2.2.1 to to mention this one...It is AMAZING that you all do not just zip up a 2.2.2 version...after all, read the site as you do...your users are asking for it! Bring this to the powers at be and lets get people all on the same version.

[tubedogg]

Originally posted by David Bott


WOW....With the number of bugs that have been reported and fixed in 2.2.1 to to mention this one...It is AMAZING that you all do not just zip up a 2.2.2 version...after all, read the site as you do...your users are asking for it! Bring this to the powers at be and lets get people all on the same version. Proportionatly there are less bugs in 2.2.1 than in any other previous version in the 2.x line. This is also the only version thus far that we have actually posted whole files for you to download instead of manually applying bug fixes.

What I said above as far as no releases planned *is* from the powers that be BTW.

[David Bott]

"What I said above as far as no releases planned *is* from the powers that be BTW."

Very said. Glad you are posting the files...but unless you *Look* for them, you can find them. Should have them all listed in the private members section for download. For even the zipped version does nopt have them..or all of them.

[tubedogg]

Originally posted by David Bott
...lets get people all on the same version.There is a large percentage of users still on 2.2.0 and there are still more on 2.0.3, some who refuse to upgrade to 2.2.x at all because of encrypted passwords. People do not upgrade just because we release a new version. The vast majority of people have indicated they would prefer upgrades spaced farther apart because of the time it takes to complete one with template editing etc.

[tubedogg]

http://www.vbulletin.com/forum/showthread.php?s=&threadid=36158

[David Bott]

Kodos! Nice! Yahoo!

[telescopi]

Thanks to Eva for pointing me to this (huge) thread :)

There are several fixes suggested here, what is the fix recommended by the developers? Indexes, PHP hacks, or both?

[David Bott]

telescopi...They have yet to say anything on this issue that has been both proven and fixed by the fine members in this thread. (Who I thank for our site is not a small site by any means and this we greatly needed.)

I personally suggest doing both...the extra index which helps a lot and the mentioned revised code that works like the wind.

[ASRacer]

My site is a rather large site and we're having problems with this issue. My forums have over 24,000 registered users and around 170,000 posts. Pruning is VERY important to us. I did the one fix, but have not yet implemented the fix utilizing the new field in the database.

I can't believe that Jelsoft isn't going to issue a patch at the very least.

Chris

[TommyBALL]

Originally posted by ASRacer
I did the one fix, but have not yet implemented the fix utilizing the new field in the database.? What fix are you speaking of? I haven't found any reference to a new field in this thread...?

- Tommy

[roy7]

He may be referring to the extra index.

-Jonathan

[eiko]

I've NEVER been able to mass delete, 2.0.0, 2.0.3, 2.2.0 or 2.2.1.
I REALLY wish someone would complile the instructions in this thread in a usable way.

[DVD Plaza]

Upgraded to 2.2.1, finished making all the template changes, made some test posts, and then tried removing one of those posts.... two minutes later it finally deleted! I then fired up two separate windows and deleted two of the other threads at the same time....

That was about 25 minutes ago, and I'm still waiting...

So now I'm reading through this thread and see that it's a known problem, but there will be no fix because Jelsoft have decided to ditch any further development of vBulletin 2.x!?!?!?

I guess that means it's party time for hackers should any security problems be found with vB2.2.1...

[tubedogg]

We have not 'ditched' development of 2.x. As I think I've said, and I know John has said, if there are issues that arise that require a version upgrade (security etc.) we will release it.

[Freddie Bingham]

There will be a v2.2.2 released this month.

We always said that if there was a security issue than a 2.2.2 would be released to deal with so their is no need to suggest we would allow a known security issue to go unfixed.

There is no security issue but since we seem to have a few bugs that are affecting the admin's usage of the forum we are going to go ahead and release v2.2.2

[Kaizen]

Originally posted by freddie
There will be a v2.2.2 released this month.

We always said that if there was a security issue than a 2.2.2 would be released to deal with so their is no need to suggest we would allow a known security issue to go unfixed.

There is no security issue but since we seem to have a few bugs that are affecting the admin's usage of the forum we are going to go ahead and release v2.2.2

Perhaps it might of been better to keep this quite.

The "gimme, gimme" fever is going to set in now....

[Freddie Bingham]

We will release it when it is ready, not before.

[Joshua Clinard]

Thanks! That's what I wanted to hear. I'm not in a rush though, so take your time, and just do the best you can.

[Floris]

Originally posted by Kaizen


Perhaps it might of been better to keep this quite.

The "gimme, gimme" fever is going to set in now....


Already started here, and I only have it for 6 days now :D

Also, I am having double fever, running 50oC because I heard they are working on v3 also ....


AHHH GIMME GIMME :D


I seriously love this forum software.. It is one of the top3 software I bought in the last year ..

But I seriously!! do not mind waiting 3 more months, or 'whatever' it takes to get the job done, and the job done right.

I rather see developers take their time and do the right thing, then be a microsoft product that gets released just to keep the folks happy.

[Deyth]

Has a fix for this become available somewhere? I have about 10,000 posts to prune, 20-30 at a time is painful.

[Alex]

Can someone give me the correct sql-queries for manually doing it? It is really really urgent!!! Have to delete a thread with 1400 Posts. And i want my searchindex clean... :(

[TommyBALL]

Originally posted by AlexD
Can someone give me the correct sql-queries for manually doing it? It is really really urgent!!! Have to delete a thread with 1400 Posts. And i want my searchindex clean... :( You find the SQL-qeury in this post...
http://www.vbulletin.com/forum/showthread.php?s=&postid=209381#post209381

If you have lots of attachments, you have to do the attachment changes as well, but that is not in SQL. It's in the PHP code. The solution is here...
http://www.vbulletin.com/forum/showthread.php?s=&postid=209899#post209899

Additionally there are some improvements to the attachment fix by roy7 in this post, and the post following it by the same author.
http://www.vbulletin.com/forum/showthread.php?s=&postid=225090#post225090

Combined this is the complete and very well testet fix to this problem.

Regards
- TommyBALL

[dvdtalk]

I've updated my functions.php with the code from this thread but when I go to add a postid index to my DB with


ALTER TABLE searchindex ADD INDEX postid


I also get the error:


You have an error in your SQL syntax near '' at line 1


any advice?

[roy7]

Try

ALTER TABLE searchindex ADD INDEX (postid);

-Jonathan

[dvdtalk]

Thanks....

My fear is that our searchindex is so big (18813835 records) that we will need to shut down our forum for a few hours.... Anyone have any idea how long building this index should take?

Would it be faster to drop the searchindex add the postid index and then reindex the site???

We need to purge a number of threads, should we do this after adding the postid index or is there a way to do it after we drop the searchindex and before reindexing??

- Geoff Kleinman
DVDTalk.com

[roy7]

Oh hi Geoff, been a while. :)

It won't be faster to drop, index, and remake since it has to do the same indexing work anyway but you'd have to build a whole new searchindex. It could take a while to add the column. I doubt over an hour though. My suggestion is to take the site down during a slow hour, add the index, then bring it back live.

Dropping after you add the index should be faster. That's why this index is added I think, so you can pull searchindex rows by postid # without looking over all of them.

-Jonathan

[dvdtalk]

Thanks everyone for the help. I shut down the forum last night and added the index via the command line and it worked great. We can actually edit and delete posts now!!!

- Geoff

[John]

Version 2.2.2 includes a better function to remove posts from the search index, so this problem should be fixed.

John

[NYI Fan]

Any ETA for that release? My forums need a good clean up, but as things stand, I can't do that excpet 15-20 posts at a time...

Thanks!