Alvin basically gave you all the needed info for acomplete answer already, but let me elaborate a bit with my own information.
So a while ago I started with a Child Publications Only Resolver created as a comment on Alvins article. This is most likely close to what you have implemented in your custom resolver. But I wonder if what you are doing is exactly the same and if it is entirely correct, since you say that you end up with a lot of empty Publish Transactions in the queue. When using my solution, you would end up with just 1 empty Publish Transaction (something which I wouldn't think to be in the way as such) and a lot of full transactions for each child Publication.
But lets say you are bothered by those empty Publish Transactions, and certainly because they have a status of success. That is where my next tool came in, using an Event Handler to change the status of an empty Publish Transaction to Warning. Yeah nice I heared you say, but I want to get rid of them. Well that is when I invite you to look at the code of the event handler, and start to work with it (I wrote that code as an example, not just as a solution).
So what it currently does is change the state:
if (subject.PublishContexts.ProcessedItems.Count == 0 &&
XmlDocument delta = new XmlDocument();
"This Publish Transaction contains 0 (zero) items.",
But perhaps more importantly, it does this by subscribing to the following event:
So it is using the event phase
Initiated, and what you want to do is delete the transaction all together. To be able to do that, you cannot do so while still in transaction, so you need to look at the event phase
TransactionCommitted. Now with this knowledge, you could adjust my event system and call
subject.Delete() (when you have located an empty transaction, and it is in its final state change, so that would be
Warning depending on what you all did before).
This is basically what Will did in his event handler: https://gist.github.com/willprice76/9639405