I agree with Matt. Databases are designed to enable quick retrieval from tables of gigabyte and terabyte size. Don't worry about it.
Just be sure that the row you are using as a selector (typically an auto-increment unique ID) is indexed.
Beginners often make make messes out of their data models because they're worrying about non-issues like having a thousand rows in a table instead of worrying about real issues like clarity and maintainability.
If you look at the horrible mess that underlies most of the PHP-Nuke-derived portal systems, you'll see what I mean.
In a simple forum system, you probably don't even need separate tables for "threads" and "posts." A thread is a relationship among posts, not a separate entity. Think about it.
When I built my own forum system, I did use separate tables, but I had an additional requirement.
I basically had two concepts -- containers, and messages. A container could contain messages (in which case it was a discussion), or it could contain other containers (in which case it was a folder). This allowed an arbitrarily extensible system of organizing things.
I also had a separate table for users, and a relational table that stored the "high water mark" for each user in each discussion. This allows people to participate in discussions of arbitrary length without losing their minds.
If you look at some of the message boards on the Web based on Web Crossing (Salon, Star Tribune, NY Times), you may find discussions that have lasted for many years with tens of thousands of postings, but the users have no trouble navigating.
