Wedge

How would that work...? That plugin doesn't benchmark anything...I haven't decided whether to vote or A or B. For B, how would viewing albums work?

No, but you get a lot of data to work with to be able to understand how running a larger forum is likely to handle the extra load.That's a very good question. What it means to me is that MessageIndex.php needs an overhaul, possibly loadBoard() needs to identify the type of board involved and when we would otherwise divert to MessageIndex, we figure out which file needs to be loaded for that type of board.I don't think it's true, I know it is, but I also know the author's an idiot in the first place - SELECT * and SELECT field, table.* levy their own issues, and I suspect something interesting would happen if the author didn't just blindly select * from anywhere.

Anyway, yes, the point is correct: if you do a query where you're sorting by any column and there's a TEXT or larger field in there, it will generate a disk-based temporary table (this is what a filesort is). Getting around it using a subselect is an interesting way of doing it, but essentially yes it's correct, it fools the query parser as to how the table is generated and it means it isn't implicitly a filesort. At that point you just have to hope MySQL can get enough memory to do it in memory otherwise you end up with a filesort anyway.

It's also why Display, for example, gets the message ids first, then fetches messages separately.

Yep.First, I think that we should build a mini-plugin system for floating boards.
MessageIndex.php would load the main stuff, then would determine the board type and call MessageIndex-Blog.php or whatever. (Or just the corresponding template.)
Same for Display -- Display-Blog.template.php, etc.
This would probably help performance if implementing tons of board types. Also helps with plugins enabling their own board type...?

Now, as for your comment, I'd just like to say that nothing prevents MessageIndex from redirecting to the current code in the /media/ folder. Well, what I really mean is, solution (A) would change the album URLs to use something in the style of board URLs, while solution (B) would keep using ?action=media;sa=album;in=123 where the albums table stores id_album = 123 and id_topic = 345, and id_topic is a custom topic created in a custom (unique) board. The main point is that the code changes are limited, the main drawback is that you can't set up board permissions on the album, rather you have to use the current album permission system -- of course the album permission system is currently better because it offers to ban/allow users on a case by case basis, while boards, and will force you to create a custom group just to allow or deny someone.
I'm not sure what the best would be... Hence my poll.

Heck, the C and D solutions are also complex in that they effectively remove 'albums' from possible 'floating boards', instead having a single hidden board hold all of the albums as topics.

(Of course, I could also have added another suggestion where we have a single hidden board to represent the gallery, and then one topic per item -- with the item/album/category relationship being maintained in the media tables. That would make sense, too...

So, to keep it short, solution A makes the most sense if we want to go fully 'floating boards'. Other solutions might be better for performance. I don't know.That's... Very funny.
Well, thankfully, MySQL queries can be optimized later on, they don't have to be static :)