How is the "Subscribed Threads" workaround NOT a Search?

Just wonderin’. In this thread, Senor Beef taught me how to keep track of what I’ve posted in by using the Subscribed Threads in my User CP. When I look at that list, it tells me what has new posts in it since I last looked, which is cool.

But how is this not a Search? How come this doesn’t screw up the hamsters like Searching for my posts by “Show all posts by this user” does?

Or does it, but not as many people are doing it, so we aren’t seeing the same rate of board crashing from it?

(If replies could contain small words in Captain Dummy Speak, that’d be awesome. I’m fairly dumb about computer stuff, but curious.)

Without knowing the inner workings of the vBulletin software, take this with a grain of salt… but, it’s my best guess, based on a bit of DB programming knowledge.

When you subscribe to a thread, I suspect that the thread ID is entered into your list of subscribed threads in the database. When you go to list those threads, each gets pulled up and the last post in the thread is checked against your last login time. So really, I guess you could say you’re performing a search within a MUCH smaller group of threads – I’m subscribed to about 120 threads, compared to the 369,000 on the entire board. Pulling up the last post in 120 threads and checking it against your last login would be nowhere near as intensive on the server as searching for “huckabee campaign” among 369,000 threads.

Again, just a guess, but I’m pretty sure this is at least close to how it works.

My guess would be that the threads you see in your subscribed list are little different from current threads. When you click on one of them you aren’t searching for anything; you are simply clicking a thread title just like in the forums.

Thanks, guys! Both of those make sense. (Whether or not they’re correct, I can’t say, of course. But they both make sense!)

Since neither is a full text search (which is what really hammers the database), you’re correct that “find all posts by user” isn’t intrinsically more difficult than finding all their subscriptions. In essence they just select all entries with a particular userid from the “post” and “subscribethread” tables respectively, which is pretty quick. The subscribethread table is likely to be a lot smaller than the post table, but for simple select statements that shouldn’t make a whole lot of difference.

As far as I can tell, the only reason why one is disabled and the other not is that the code for each is in different files. The “searchdisabled” option that they’ve switched on effectively blocks off all access to search.php, including the “finduser” action. There’s no such check in subscription.php, so that still works. I s’pose they could hack search.php to allow just the finduser action, but they’ve never seemed keen to modify the code in the past, and with good reason.

I’m looking at a much newer version of vBulletin, to be fair, but I can’t see it being radically different on this point.

Er, I just realised I completely failed to make that particularly comprehensible. I’ll try in slightly less techie speak.

The long and the short of it is that you’re right: they’re both as easy as each other, and the only reason one works and the other doesn’t is because vBulletin is written that way. What really hammers the database is full text search, i.e. when the board has to actually look inside the content of each post to look for individual words and phrases. When it’s looking for something easy, like all posts by a certain user, or all threads a particular user has subscribed to, it already has that information readily accessible, since all posts and subscriptions have a “userid” tag on them that it can just look up directly.

Think of the difference between looking up a particular word in the dictionary, and finding all definitions containing a particular word. The former is very easy due to the dictionary’s structure, the latter very hard because you have to inspect every definition.

Unfortunately, the code for “find all posts by user” is lumped in with the full text search in “search.php”, all access to which is blocked at the moment. No more rhyme or reason to it than that, I’m afraid, but there’s not much the admins can do about it short of hacking around with the board code.

So it IS a search, kinda, or at least as much of a search as “Find posts by user” - which is an easier search than keyword searches. But because of where the command is in the software, this particular easy search is not turned off but the other one is?

I think I got it. Thanks!