You can think of it like faceted search, except instead of just getting a count, you get the top documents for that constraint or category. There are tons of potential use cases:

• For web search, only show 1 or 2 results for a given website by collapsing on a site field.
• For email search, only show 1 or 2 results for a given email thread
• For e-commerce, show the top 3 products for each store category (i.e. “electronics”, “housewares”)
• Hiding duplicate documents at query time.

In addition to being able to group by the values of a field, you can also group by the values of a function query. Given that geo search works as a function query, this also opens up possibilities for showing top query matches within 1 mile, between 1 and 2 miles, etc.

Just like faceting, we’ll be adding new functionality and making continual improvements.
Result Grouping is documented on the Solr Wiki, and you will need a recent
nightly build of Solr 4.0-dev to try it out (just make sure it’s dated after this post).

I’m particularly excited about a few things:

1. Massive scalability capabilities via distributed search, indexing and shard management – Up until now, Solr scales pretty well on the search side (I’ve seen billion+ document instances and we’ve benchmarked it at that level too), but the work underway in Solr 1.5 will take it to a whole new level, thanks to the integration of Apache ZooKeeper and other distributed technologies.  For those interested, check out the “cloud” branch in SVN.
2. Functions, functions, functions!  We’ve already added a bunch of functions (see my earlier post) and I see more on the horizon.  Additionally, I see great value in adding, for lack of a better phrase, aggregating functions to the mix (via SOLR-1622).  This will allow application designers to do much more sophisticated math across a search result set than what is currently available via the StatsComponent.  In some ways, this can empower business intelligence applications on top of Solr (I realize it is just a small piece of the BI pie) as well as more sophisticated mathematical applications.
3. Spatial Search!  It’s funny, a lot of people want spatial search and Solr could have simply harnessed a really nice existing package (LocalSolr) just as many already do, but by stepping back and taking a look at spatial in the context of the bigger picture of things (see SOLR-773) that would be nice to have in Solr, the community will be able to not only implement spatial search (by leveraging key pieces of LocalSolr where appropriate), but will also get a whole bevy of other features, including:
   1. Sort By Function – Instead of a one off that sorts solely by distance, why not enable Solr users to sort by any arbitrary function? I just committed this tonight via SOLR-1297.
   2. “Poly” Field Types – Thanks to SOLR-1131, Solr’s FieldType mechanism can be used to represent multiple underlying fields.  This is especially useful for representing things like points in an n-dimensional space, Cartesian Tiers (zoom levels) and other cool things.  Moreover, it shows the types of abstractions Solr can overlay on the already powerful Apache Lucene to provide even more functionality.
   3. Facet By Function – Sure, it’s great to put your distances into buckets, but why not put the result of any function into buckets?  See SOLR-1581.
   4. Spatial Query Parsers – aka geocoding – Parse things like street addresses, etc. and get back appropriate Query instances. See SOLR-1568 and SOLR-1578.
   5. Several different distance functions, including haversine (great circle), Manhattan, Euclidean (Solr actually now supports all p-norms as distance functions.)  See SOLR-1302.  I even added in the ability to do String distance calculations using Levenstein (edit), Jaro-Winkler, n-gram (basically all of the Lucene spellchecker distance measures, as well as any user defined String Distance calculation.
   6. “pseudo” fields – Instead of just hacking the ability to put a distance calculation into the result, why not allow the response to stream out “fields” based on things like functions or other user defined values?  See SOLR-1298.
4. Field Collapsing – I haven’t had time to work on it, but I suspect Field Collapsing will finally make it into 1.5.  Field Collapsing allows Solr to “roll-up” similar results much like you see on many Internet search sites that indent results from the same domain.
5. Payload and Span Query support – Solr’s been able to index payloads for some time now, but it still requires a user to hook in their own query parser support.  It would also be really great to see functions that can work on payloads, too. See SOLR-1337 and SOLR-1485.

Of course, as I always say, “in open source, you never know where the next good idea is going to come from”, so I have total faith that the Solr community will come up with a plethora of other great new features, as well as the usual bug fixes, etc.