What is meta? ×
Meta Stack Exchange is where users like you discuss bugs, features, and support issues that affect the software powering all 128 Stack Exchange communities.

Why are the search result counts different for the different tabs?

Example 1: +hibernate "forced de-tag" search

Example 2: attribute regular non-tag search

share|improve this question
    
Are those tabs supposed to be sort views? Maybe there are hidden metrics to split up what posts show in each tab slot if at all. –  random Feb 18 '11 at 5:27
    
@random: Yes. They are sorts. I can see how "Active", for example, might return a different number, but not the others. –  Dennis Williamson Feb 18 '11 at 5:55
add comment

1 Answer 1

up vote 1 down vote accepted

This is a bit of a side-effect of how we do things in presentation. When it comes to searching for terms that may appear in multiple answers in the same question, we "roll up" to the question for presentation (in most cases). To keep things sane, we're only querying about 5,000 posts from our search index before this rollup occurs.

Now there's 2 factors in play here, a "roll-up" has to be occurring (this isn't always the case, for example a votes: search won't roll-up...answers have votes too, isaccepted: is another example). Also, your search has to be non-specific enough to return over 5,000 results, making the roll-up take that number back under 5,000 to varying degrees.

This means your most likely candidates for seeing this are questions with lots of answers and a very broad topic returning many matches overall as well.


Now why does this happen per tab? Well it's how the answers are being sorted. For example sorting by votes may find a big, possibly older, question with a lot of answers that have high votes. Every answer on that question would roll-up to that question producing a single search result rather than n search results, this really cuts into that 5,000 for big questions. Take the same search sorted by active...well those answers on that big question may fall off the list completely, and those with a lower answer-search-results-to-questions ratio will appear as the first 5,000 matches coming back, and the roll-up will suffer less of a trim in those cases.


We can't realistically (from a performance perspective) prevent this from happening in most cases, but it can and has been improved for the next build. I added a search result buffer zone for the roll-up scenarios that'll fetch some (many) more results before trimming them down to the 5,000 (this is set per-site, but 5,000 everywhere at the moment). If your search hits a lot of questions with a ton of matching answers each...well, you'll see different numbers. For most cases though, this buffer will fix the issue, and you'll see "5,000+" as the count on the right.

share|improve this answer
add comment

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .