there are a few big board sites using this although I don't know their volume levels. Keep in mind that while there are queries when someone votes under the default settings none are added to the showthread page... Instead there is a join on the existing query and some php conditionals.

I suspect the biggest issue will be installing the mod as it adds two fields to the post table which can take sometime if your site has a few million posts.

8 and a half million. Might it be worth combining the two alterations to the post table into one query?

At 8.5 MM posts I'd actually suggest removing the table alter queries from the plugin entirely and running them via mySQL shell to avoid a timeout from your browser or the potential impact of a failed connection part way through.

Okay I've tested some things and text other than $helpful_answers (for example, random text) will appear on every post when inserted where $helpful_answers should be. When using either automatic or manual insert mode, it still only shows on the first post of each page. This is also true on a default style I installed that has no customizations at all.

Is it at all possible to have this mod without altering any tables? Surely best practise would be not to alter the vB tables, but add new tables where needed?

There's no best practice I'm aware of to avoid editing tables. Counts are stored with the post table because that's what's already being called.

It's certainly possible to do just about any mod without altering existing tables but I chose to alter the ones that made sense to alter as opposed to increasing queries and load by adding new ones which have to joined in.

Please check your settings and let me know if you have enabled the mod to not show in the first post.

Thanks for the reply. I'm of the feeling that it's probably not a good idea to alter the core tables of vBulletin even though so many hacks do it - including the immensely popular Post Thanks mod.
If the post table is absolutely huge like ours then it could possibly be argued that adding a couple of fields may have more detrimental effect than adding a new table and join element to the sql.

What drew me to your mod was the system they have on http://www.hotukdeals.com/

Definitely good points although I'm clearly not against to editing the tables for logical storage and felt that it was appropriate here as what I was storing was summary post information. My pet peeve is when mods use generic names on their edits causing future updates or other mods to conflict... which is why I tend to use longer and more obscure field names.

For a larger board having the data stored in another table may make more sense although I'm not sure which is better (holding two more fields or joining one more table). Any ideas of the performance difference?

This mod would be fairly simple to extend to use a different table but I'm just not sure it's worth the import routines and work versus expanding the feature-set.

I looked at the code to be sure my last statement is right and it is... If you just wanted to do core voting without some of the profile enhancements you'd be looking at 3 or 4 edits. To get every feature down to the logs and what not working it's a bit more but still nothing crazy.