No, it wasn't, but it is an obvious case to reduce the amount of rows read.

Could be, but I like the "trust but verify" myself, as I'm never confident in what/how/why DB internals run. Anyway was just curious what the improvement turned out to be. Carry on!

Thank you, Josh! I think indeed Notifications subs are better off refactored in their own file, and perhaps also some functions signatures more consistent with others. There are quite some chunks of code there, it's far better than keeping them in Post or the like.
Good to see the finds through the whole code, too. (That's something I didn't quite do lately, how you went about it is better.)

But the PR contains other commits too, and they are not suitable. Same goes for https://github.com/joshuaadickerson/NotElkarte/commit/e1c14e7e3ae7ccfe8033906799c5db84f7475a70 which is problematic.

The way to make it easier to take in, is to rebase your Notifications PR to the master: with the higher-level notifications refactoring, and it alone.
In fact, it's almost always better to stick to one topic per PR: it's easy to switch branches, there's no reason to keep committing to the same branch, if it doesn't fit its purpose. And, there's cherry-pick and rebase for those cases. :)

I would suggest you take a look at the current notifications code too. A few changes will probably conflict with a couple of my latest changes, which have also refactored a few of the notifications too (far fewer, like one or two, with no intentions on notifications in particular).
I would also suggest to leave aside the last commit for now, the removeNotifications() function. But the rest of your moves and queries refactoring make things better in the notifications area.

@Spuds since you picked some in #988. Can we close this one?

As noted, this has been done in #988 so closing this