When the user clicks on a tab, that causes a push to all the modules downstream of the Tabs module. If there is a Search module there in the active tab, and if that Search module has dispatching modules (Table/JSChart/etc) downstream from it, then the framework will dispatch a search. There's no way around this.
However...
1) To the extent that the data from the two tabs can be combined into a single search result, and then selectively queried via different PostProcess modules, one in each tab, then you can sort of cheat.
More precisely -- you pull the Search module up above the Tabs entirely, you make sure there's some dispatching module in the right place, like a JobProgressIndicator that is a sibling of the Tabs module (ie neither downstream nor upstream but at the same level). Then you get the right bits of the data going to the right Tab with 2 PostProcess modules.
2) As ppablo_splunk mentioned, there's another post where the solution was to use a Button module with allowSoftSubmit false. http://answers.splunk.com/answers/142870/tabs-module-tab-switcher-and-timeselector With allowAutoSubmit True and allowSoftSubmit False, the Button would effectively shield the searches from being dispatched when the tab is clicked. (You would typically put "Run Again" or something as the label on the Buttons.)
As to trying to use the Gate module for this kind of solution... Gate can do a lot of weird things, but subverting the basic push/dispatch behavior of the framework is a tall order. And even if you could sort of stash jobs somewhere on the page and then render them to each tab with Gate module pushes, I think you might end up also disrupting the show/hide behavior of the Tabs module.
