lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <otis_gospodne...@yahoo.com>
Subject Re: How to limit rows to which highlighting applies
Date Sun, 22 Aug 2010 21:59:18 GMT
I didn't look at them closely now, but look at:

https://issues.apache.org/jira/browse/SOLR-1093
https://issues.apache.org/jira/browse/SOLR-2026

Incidentally, I found them with:
http://search-lucene.com/?q=multiple+queries&fc_project=Solr&fc_type=jira

Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/



----- Original Message ----
> From: Alex Baranau <alex.baranov.v@gmail.com>
> To: solr-user@lucene.apache.org
> Sent: Sun, August 22, 2010 7:51:49 AM
> Subject: How to limit rows to which highlighting applies
> 
> Hello Solr users and devs!
> 
> Is there a way to limit number of rows to  which highlighting applies? I
> don't see any "hl.rows" or similar parameter  description, so it looks like I
> need to enhance HighlightComponent to enable  that. If it is not possible
> currently, do you think it's worth adding such  possibility?
> 
> JFI my case, when I need this: I display on results page 20,  10 or 5 rows
> only, but I need much more rows (100-500) to display additional  data on the
> same page. Queries could be very complex and their execution  time
> (QueryComponent) is quite big. So I do want to fetch things via  single
> request. However, I noticed that with increasing number of rows, time  spent
> in HighlightComponent increases dramatically. For those additional  hundreds
> of rows I don't need highlighting at all.
> 
> Actually, *ideally*  it would be great to have the ability to specify fields
> returned for those  extra rows as well. So I tend to think that adding this
> features should not  be based on changing HighlightComponent behaviour, but
> changing  QueryComponent or even "bigger" part somehow so that Solr query
> accepts  specifying extra group(s) of rows for fetching along with params for
> them  (which not influence the searching process, like
> formatting/highlighting,  fields to return, etc.). Thus, we could execute
> *one* search query and fetch  different data for different purposes.
> 
> Does this all make sense to you  guys?
> 
> Thank you,
> Alex Baranau
> ----
> Sematext :: http://sematext.com/ :: Solr -  Lucene - Nutch - Hadoop - HBase
> Lucene ecosystem search :: 
http://search-lucene.com/<http://search-hadoop.com/>
> 

Mime
View raw message