I think the Gate solution is a better direction, as posted in your other question here - http://answers.splunk.com//answers/110436/search-optimization-and-caching-for-forms. Trying to use postProcess for this is going to require some stuff that'll feel pretty artificial in this case. However I can spell it out a bit.
Also, you certainly can use Sideview modules with scheduled saved searches. You just use the Splunk HiddenSavedSearch module or the Sideview SavedSearch module in place of the Sideview Search module. Aside from that it should all work as expected - shoot me an email if you had run into trouble here and we can figure out where things went sideways.
Summary Indexing is another area worth checking out, and is more applicable to your situation than postProcess frankly. http://docs.splunk.com/Documentation/Splunk/6.0/Knowledge/Usesummaryindexing This would require substantial work but would put you in a place where you had both more power and more flexibility. Form elements would render fast, even the first time, and you could suddenly do lots of things that had been impractical before.
That said, how you would do something like this and use PostProcess to get there, is that you would merge all of your saved searches and searches into one giant master search commonly called a "datacube". Then each Pulldown or Chart or Table would use a postProcess search to basically carve out of this high-dimensional cube, the data that it needed to render.
The considerable problem and I think deal-killing problem here is that not all sets of searches that you might mash together have characteristics that work as a single datacube search, and when they don't fit, the net performance can be quite a lot worse than dispatching N separate searches.
Typically if making the datacube feels artificial, like you're just arbitrarily gluing unrelated things together, then it's a bad idea.
An example off the top of my head that would lend itself well to a postprocess approach would be:
pulldown that needs to render distinct users, and have an "all users" option
Pulldown that needs to render distinct hosts, with an "all hosts" option
Pulldown that needs to render distinct applications,
chart that renders the hours of the day across the x axis and distinct users on Y, split by application
chart that renders total bytes downloaded by user.
chart that renders the most commonly used applications
base search would be:
foo bar baz | stats sum(bytes) count by user host application date_hour
and the 3 postprocess searches to drive the Pulldown:
| dedup user | sort user
| dedup host | sort host
| dedup application | sort application
and the three separate postprocess searches to drive the charts would be:
| chart dc(user) by date_hour by application
| chart sum(bytes) as bytes by user
| stats sum(count) as count by application
But I'm probably talking too much. The postProcess docs in Sideview Utils have been rewritten many times and they'll give you a stronger understanding.
... View more
