Why does the query using an absolute value return better results than the query using a subsearch?

[davidse]

A query that uses the returned (single) value of a subquery is returning different results than if I simply type in the value as a hard coded string.

Query 1:
index=cfs_* "aeb78KaLh7VIphSVg9FSIxl46y4="

Returns:
- events = 1535
- hosts = 5
- source = 19
- sourcetype = 14

Query 2:
index=cfs_* [search index=cfs_* "662704824FF6C21E" | top limit=1 sessionId | fields + sessionId]

Returns:
- events = 1331
- hosts = 2
- source = 10
- sourcetypes = 6

with "[search index=cfs_* "662704824FF6C21E" | top limit=1 sessionId | fields + sessionId]" returning: aeb78KaLh7VIphSVg9FSIxl46y4= when run by itself.

Why these two different result sets simply because the value returned in Option 2 is from a query vs. a hard coded value?

[somesoni2]

So your query 1 is this

index=cfs_* "aeb78KaLh7VIphSVg9FSIxl46y4="

The subsearch, when normalized, will be translated as (assuming the value returned is same)

index=cfs_* (sessionId="aeb78KaLh7VIphSVg9FSIxl46y4=")

So, the subsearch version expects that your data in index=cfs_* has a field called sessionId with value "aeb78KaLh7VIphSVg9FSIxl46y4=", whereas the hard-coded value version just searches that the raw data of the events in index=cfs_* has word/string "aeb78KaLh7VIphSVg9FSIxl46y4=". There may be events where the string "aeb78KaLh7VIphSVg9FSIxl46y4=" is available but not extracted as field sessionId, and thus the difference. Just to confirm my theory, please run following, for the same time range, and see if it matches your first query's result.

index=cfs_* [search index=cfs_* "662704824FF6C21E" | top limit=1 sessionId | eval search=sessionId |table search]

[davidse]

Answered my own question. This is the difference between named fields and the value itself in unmapped / un-named / different fields. This query returns the same results.

index=cfs_* [search index=cfs_* "662704824FF6C21E" | top limit=1 sessionId | fields + sessionId | rename sessionId as query]

"query" is dropped by splunk as a keyword, resulting in just the value being used for the subsequent query. Apparently you can use the "return" macro as well, but I could not get this to work.

[richgalloway]

Please accept an answer.