I've seen it suggested before and definitely have witnessed myself that for searches involving any significant amount of data, it's always light years faster to grab all the data and then figure out a way to correlate it at a later time via stats, versus using a subsearch in your base query. To illustrate what I mean, say for example you have two sourcetypes "left" and "right", each containing their own set of data that has a shared unique identifier that can correlate the data we'll call "unique_id". So why does a search like this: index=left sourcetype=left [search index=right sourcetype=right | stats count by unique_id| fields unique_id] | stats count Take massively longer (and in a lot of cases just timeout indefinitely due to memory limits of a subsearch being exceeded) than something like this: (index=left sourcetype=left) OR (index=right sourcetype=right) | eval left_count=if(sourcetype=left,1,0) | stats values(sourcetype) as sourcetypes, sum(left_count) as left_count by unique_id | search sourcetypes=*left* sourcetypes=*right* | stats sum(left_count) as count I'm wondering why subsearch is always so much slower for something like this? ... View more

I've tried this with multiple fields now and the same behavior occurs. What I want is simple: To auto extract a field, and have it rename to something else so that I don't have to constantly pipe in a rename when I do tstats calls against the data model. Based on my understanding, when I set up the data model and give the field a display name, should this not essentially rename the field? Because this does not seem to be what it does, and in fact I have no idea where the Display Name ever comes into effect. I don't see it showing up anywhere aside from in the data model field list. For instance, let's say I have a field "dimension" in a source that a data model is pulling in from via the constraints. Now I add this field via Add Attribute -> Auto Extraction and set the rename to instead be "status" instead of "dimension". Now, when I try to do a tstats call, it still only recognizes the field if I call it by the name of "dimension". If I try to reference it by "status" I get nothing. So am I misunderstanding what this rename is suppose to be doing, or is there some caveat that prevents my tstats call from recognizing that fields are supposed to be renamed? ... View more

I have a set of around 5 dropdowns, where each sequential dropdown is populated by values that depend on the dropdown before it. I am using selectFirstChoice set to true in order to update them as values are reselected, and what I am noticing is this: Let's say I have dropdown "A" and dropdown "B". "B" has a set of values that pull a search using the value selected in "A". Let's say I have "A" set to a value of "male" which allows a bunch of male names, and "B" is set to some arbitrary male name like "John". Let's also say I have graphs below populating based off this selection data, and it's giving me the proper "John" data. Now, let's say I make a selection to "A" and change it to be "female". Now what happens is that I notice the graphs will repopulate with new data specific to whoever the first selection would be for the female names, let's say "Sally". But visually, the dropdown for "B" is still selected to "John". It isn't until I click on it that I see the male choices are no longer available and only female choices are there - even though the data for B clearly already had changed to a choice within that list, yet visually never moved away from John. My goal here is to have the "B" dropdown visually change to Sally when the selection on "A" is changed, especially since the data is already clearly selecting the value - so that I can both eliminate any confusion at the data being displayed, and just have a more smooth user experience. Anyone know what extra I need to be doing here in addition to selectFirstChoice set to true? ... View more