Okay, lets take a different approach here ...
join is not the join one knows in the DB world. join is one of the most inefficient SPL commands, and has a lot of limitations, by using sub searches, that you can hit even without knowing you hit them http://docs.splunk.com/Documentation/Splunk/latest/Search/Aboutsubsearches#Subsearch_performance_considerations
On the other side stats is one of the most efficient SPL commands you can use, more here https://answers.splunk.com/answers/129424/how-to-compare-fields-over-multiple-sourcetypes-without-join-append-or-use-of-subsearches.html or here http://sideviewapps.com/slides/2017_05_02_sideview_let_stats_sort_them_out.pptx
That said, if you combine two searches as base filter, and make them as specific as possible by using all metadata fields index , source , sourcetype , and host as well as all needed fields like foo=* and/or bar=* and add the fields command http://docs.splunk.com/Documentation/Splunk/latest/SearchReference/Fields after the first | you will tell Splunk just to look for and return these fields. In addition using stats you will make Splunk to use map reduce and parts of the search results are pre-processed on the indexers.
Any search using sub searches will be most likely run twice as long (there are exception) and put more load on the servers. So by using a join you actually do exactly what you mentioned as reason you don't want to use a stats search 😉
Hope this makes more sense now, and give it a try and compare the run times of the join search and of the stats search ... I'm pretty confident you will no longer use join after this comparison 😉
cheers, MuS
... View more