Appendcols, append, subsearches...
I don't think they work like I think you think they work. (Lol, what a sentence).
Here's a simple run anywhere example:
| makeresults | eval outside_appendcols=time() |appendcols [| makeresults | eval inside_appendcols=time()]
| eval inside_appendcols_ran_first_by = outside_appendcols - inside_appendcols
Depending on how fast your system is, you'll see that the appendcols actually runs first.
In any case, I think - both from the question and from the code you wrote - that you are approaching SPL as if it's a regular, procedural language. It's fairly step-by-step if you don't use subsearches or anything else in [] brackets , but once you do then it's all backwards. Subsearches and [] bracketed things run first, not last.
And in the best event, I'd never try to rely on the order of them. They're not linear. I could probably construct a run-anywhere example that checks in what order half a dozen subsearches in different places in some SPL would run, and you'd see what a mess it would be, but I think you get the idea.
So where does that leave us?
In my opinion, I think maybe too much is being done in one big fell swoop there. This has the feel of being 3 or 4 different discrete steps - maybe a summary index, maybe another lookup or two, I'm not really sure at this time, but certainly the feeling that it's trying to do too much in one piece of SPL.
I think we'd be happy to help, but would need more information about what you are trying to actually accomplish and from what data you are starting from?
(Also, the search itself is pretty impressive, I don't think I've seen such an amount of programmatic work done inside SPL ever!)
... View more