In this section, we discuss the Executable Results table. Each row of this table corresponds to one executable in the database. The information in one row is an aggregation of all of the function-level matches into that row's executable. Here is an example Executable Results table from the previous query (yours may look different depending on the compiler used to create the example files):

If you select a single row in the table and right-click on it, you will see the following actions:
foo has 2 or more matches into a given executable, it still only contributes 1 to the function count).
What position is demangler_gnu_v2_41 in your table?foo has more than one match into a given executable, only the one with the highest (function-level) confidence contributes to the (executable-level) confidence score.
Sort the Executable results by descending confidence and observe that demangler_gnu_v2_41 is now further down the list.
demangler_gnu_v2_41 and apply the filter action.
Sort the filtered function matches by descending confidence.
Starting at the top, examine some of the matches and convince yourself that the given explanation is correct.
in the toolbar.
We'll discuss this further in BSim Filtersdemangler_gnu_v2_41 and query all functions in postgres again, this time with a Confidence bound slightly higher than this confidence value. Verify that demangler_gnu_v2_41 is not in the list of executable matches.From this exercise, we see that unrelated functions can be duplicates of each other, either because they are small or because they perform a common generic action. Keep in mind that such functions can "pollute" the results of a blanket query. In the next section, we demonstrate a technique to restrict queries to functions which are more likely to have meaningful matches.
Next Section: Overview Queries