Databases Reference
In-Depth Information
<option name="displayRowNumbers">true</option>
<option name="maxLines">10</option>
<option name="segmentation">outer</option>
<option name="softWrap">true</option>
</event>
</row>
</form>
This will work exactly like our previous example but will only run the query once,
drawing more quickly, and saving resources for everyone.
Post-processing limitations
When using
<searchPostProcess>
, there is one big limitation and several smaller
limitations that often mandate a little extra work:
1. Only the first 10,000 results are passed from a raw query. To deal with
this, it is necessary to run events through
stats
,
timechart
, or
table
.
Transforming commands such as
stats
will reduce the number of rows
produced by the initial query, increasing the performance.
2. Only fields referenced specifically are passed from the original events.
This can be dealt with by using
table
(as we did in the previous example)
or by aggregating results into fewer rows with
stats
.
3.
<searchPostProcess>
elements cannot use form values. If you need the
values of form elements, you need to hand them along from the initial query.
4. Panels cannot use form values in a
<searchString
> element if they
are referenced in the top level
<searchTemplate>
element. This can be
accomplished in advanced XML, which we will cover in
Chapter 8
,
Building
Advanced Dashboards
.
The first limitation is the most common item to affect users. The usual solution
is to pre-aggregate the events into a superset of what is needed by the panels.
To accomplish this, our first task is to look at the queries and figure out what
fields need to be handed along for all queries to work.
Panel 1
Our first chart applies this post-processing:
timechart count as "Error count" by network
Search WWH ::
Custom Search