IMPORTANT ANNOUNCEMENT REGARDING PMs!

[Mindi]

Going to something completely different. UBB has been going downhill for years now and parts of our version are just plain broken and it's not even worth upgrading to stay on software that is behind the times. We're moving to what is basically the standard among forum software right now which is vbulletin. I know I will hear some ahem complaining (to put it nicely) about the change in software as I know there are some who love phpbb since it's a free product and feel we should move to that, but we went with what we felt will offer us the most as far as flexibility, support and active modding community.

This should bring a lot of cool changes for the users and for the company. The whole site is getting a redesign as well courtesy of Tim. In addition, press releases are being 'automated' to a certain extent so that the news page is not being manually updated (you may have already noticed the new press release forums I have been putting up recently).

The only thing staying the same is the store.

[Fyron]

So long as it isn't UBB, we are happy.

[douglas]

I notice you mentioned in the Dom 3 forum that about 100000 PMs were taking longer than everything else put together. Considering there are over 5 times that many posts alone, plus the user list and various other data on top of that, I can't think of any reasonable explanation for it other than an index or constraint requiring excessive redundant checking.

My first guess would be that the PM content column has a unique constraint but no index, which would force a string comparison of each and every PM with each and every other PM. This isn't that big a deal in normal use when you only have to worry about one new PM at a time, but doing 100k at once takes forever. Removing the constraint in this case would drop the import time immensely. Creating an index for it instead would greatly reduce the number of comparisons required, but the index itself would take some extra resources to maintain. Assuming my guess is correct, I would first try creating an index for the column and see how much that helps. If it still takes too long, then remove the constraint entirely before importing and then see if it can be added back in a reasonable amount of time.

Edit: Then again, I don't know that much about how most databases handle indexes on strings specifically, so it's possible that it does have an index on PM content and that removing that index could help. I doubt this is the case, but it might be possible.

[Mindi]

Like I said, I don't know all the finer points of this sort of thing. I do know what Richard did to speed up the main part of the import was to take off the indexing, but I don't think the PMs work the same way and we still haven't figured out what the total time will be once we put the index back on at the end because we haven't had a complete, successful import to try it on yet since the PM part failed last time.

I don't really like talking about all of this because it's not my area of expertise and I only know a little bit about everything Richard is doing. He's the back end, I'm the one putting in modifications, tweaking settings, importing smilies, etc.

[gregebowman]

For someone who's still has one foot in the 20th century, what the heck is a PM?

[douglas]

I have no actual knowledge of how this particular database is set up, but that doesn't make much sense to me unless the database is poorly designed or certain kinds of redundant checking are involved. Is there, by any chance, a constraint that all PMs have to be unique to prevent accidental double-sending or some such? I could see that making an import take forever by forcing the database to compare each PM to all previous PMs before inserting it. If such a constraint does exist, removing it temporarily for the import should speed things up dramatically.

[Mindi]

I don't understand the full way that it is set up, I only know tid bits of what Richard has explained to me and I know UBB has a lot of backwards way of doing things so who knows. All I know is the import started out taking the better part of a whole day, Richard has done a lot of research and found a way to speed up the majority of the process, but the PMs database still takes 4-5 hours (as much as all of the other parts of the import combined) and last time it failed totally towards the end of the PM import.

Frankly we should have put some contraints around PMs before now, but it is what it is and we're dealing with it now.