+1
q and fq both can be cached.
--
View this message in context:
http://lucene.472066.n3.nabble.com/fq-vs-q-parameter-tp4071748p4071759.html
Sent from the Solr - User mailing list archive at Nabble.com.
is message in context:
http://lucene.472066.n3.nabble.com/fq-vs-q-parameter-tp4071748p4071758.html
Sent from the Solr - User mailing list archive at Nabble.com.
>
>
>
>
> {!switch case='*:*' default=$fq_bbox
> v=$fps_latlong}
>
>
> _query_:"{!bbox pt=$fps_latlong sfield=geo
> d=$fps_dist}"^0.2
>
>
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/fq-vs-q-parameter-tp4071748.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
this message in context:
http://lucene.472066.n3.nabble.com/fq-vs-q-parameter-tp4071748.html
Sent from the Solr - User mailing list archive at Nabble.com.
Hmmm, are you talking about SOLR--2429? Some context would help here...
But if you are, that capability was added to deal with situations where
calculating the fq for the entire corpus *then* applying it to the query
results was too expensive. So when you specify one of these "high cost"
filters,
I know that fq's are used to improve performance by reducing the data set that
you score.
I have read the documentation that says that non-cached fq's are created in
parallel to your query, but would like to know more about how that is done.
Does it do a match on all the FQ's, then AND the resu
Fergus McMenemie schrieb:
While q= and fq= affect the "results" portion of a search response.
The facet.query only affects the "facets" portion of a response.
facet.query(s) are only used where you want a facet summary of your
query based on some kind of complex expression rather than the terms
>Fergus McMenemie schrieb:
>
>> The article could explain the difference between fq= and
>> facet.query= and when you should use one in preference to
>> the other.
>
>My understanding is that while these query modifiers rely on the
>same implementation (cached filters) to boost performa
Shalin Shekhar Mangar schrieb:
On Mon, Jun 15, 2009 at 4:39 PM, Michael Ludwig
wrote:
I think if you truncate dates to incomplete dates, you effectively
also lose all the date logic. You may still apply it, but what would
you take the result to mean? You can't regain precision you've
decided
Fergus McMenemie schrieb:
The article could explain the difference between fq= and
facet.query= and when you should use one in preference to
the other.
My understanding is that while these query modifiers rely on the
same implementation (cached filters) to boost performance, they
s
On Mon, Jun 15, 2009 at 4:39 PM, Michael Ludwig wrote:
> I want to retrieve documents (TV programs) by a particular date and
> decided to convert the date to an integer, so I have:
>
> * 20090615
> * 20090616
> * 20090617 etc.
>
> I lose all date logic (timezones) for that date field, but it work
Ensdorf Ken schrieb:
I ran into this very issue recently as we are using a "freshness"
filter for our data that can be 6//12/18 months etc. I discovered
that even though we were only indexing with day-level granularity, we
were specifying the query by computing a date down to the second and
thu
On Sat, Jun 13, 2009 at 1:36 AM, Ensdorf Ken wrote:
> I ran into this very issue recently as we are using a "freshness" filter
> for our data that can be 6//12/18 months etc. I discovered that even though
> we were only indexing with day-level granularity, we were specifying the
> query by compu
> -Original Message-
> From: Fergus McMenemie [mailto:fer...@twig.me.uk]
> Sent: Friday, June 12, 2009 3:41 PM
> To: solr-user@lucene.apache.org
> Subject: Re: fq vs. q
>
> >On Fri, Jun 12, 2009 at 7:09 PM, Michael Ludwig
> wrote:
> >
> >> I&#
>On Fri, Jun 12, 2009 at 7:09 PM, Michael Ludwig wrote:
>
>> I've summarized what I've learnt about filter queries on this page:
>>
>> http://wiki.apache.org/solr/FilterQueryGuidance
>>
>
>Wow! This is great! Thanks for taking the time to write this up Michael.
>
>I've added a section on analysis,
On Fri, Jun 12, 2009 at 7:09 PM, Michael Ludwig wrote:
> I've summarized what I've learnt about filter queries on this page:
>
> http://wiki.apache.org/solr/FilterQueryGuidance
>
Wow! This is great! Thanks for taking the time to write this up Michael.
I've added a section on analysis, scoring a
Michael Ludwig schrieb:
Martin Davidsson schrieb:
I've tried to read up on how to decide, when writing a query, what
criteria goes in the q parameter and what goes in the fq parameter,
to achieve optimal performance. Is there [...] some kind of rule of
thumb to help me decide how to split things
Fergus McMenemie schrieb:
On Tue, Jun 9, 2009 at 7:25 PM, Michael Ludwig
wrote:
A filter query is cached, which means that it is the more useful
the more often it is repeated. We know how often certain queries
arise, or at least have the means to collect that data - so we
know what might be c
>On Tue, Jun 9, 2009 at 7:25 PM, Michael Ludwig wrote:
>>
>> A filter query is cached, which means that it is the more useful the
>> more often it is repeated. We know how often certain queries arise, or
>> at least have the means to collect that data - so we know what might be
>> candidates for
Shalin Shekhar Mangar schrieb:
No, both filters and queries are computed on the entire index.
My comment was related to the "A filter query should probably be
orthogonal to the primary query..." part. I meant that both kinds of
use-cases are common.
Got it. Thanks :-)
Michael Ludwig
On Tue, Jun 9, 2009 at 11:11 PM, Michael Ludwig wrote:
>
> Sorry, I don't understand. I used to think that the engine applies the
> filter to the primary query result. What you're saying here sounds as if
> it could also pre-filter my document collection to then apply a query to
> it (which shoul
Shalin Shekhar Mangar schrieb:
On Tue, Jun 9, 2009 at 7:25 PM, Michael Ludwig
wrote:
A filter query should probably be orthogonal to the primary query,
which means in plain English: unrelated to the primary query. To give
an example, I have a field "category", which is a required field. In
th
On Tue, Jun 9, 2009 at 7:25 PM, Michael Ludwig wrote:
>
> http://wiki.apache.org/solr/SolrCaching - filterCache
>
> A filter query is cached, which means that it is the more useful the
> more often it is repeated. We know how often certain queries arise, or
> at least have the means to collect th
Martin Davidsson schrieb:
I've tried to read up on how to decide, when writing a query, what
criteria goes in the q parameter and what goes in the fq parameter, to
achieve optimal performance. Is there [...] some kind of rule of thumb
to help me decide how to split things up when querying against
utch
- Original Message
> From: Martin Davidsson
> To: solr-user@lucene.apache.org
> Sent: Wednesday, June 3, 2009 4:15:55 PM
> Subject: Re: fq vs. q
>
> On Wed, Jun 3, 2009 at 1:53 AM, Marc Sturlese wrote:
>
> >
> > It's definitely not proper documentation but
some
> > kind of rule of thumb to help me decide how to split things up when
> > querying against one or more fields. In most cases, I'm looking for
> > exact matches but sometimes an occasional wildcard query shows up too.
> > Thank you!
> >
> > -- Martin
&g
gt; >
> > -- Martin
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/fq-vs.-q-tp23845282p23847845.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>
>
nst one or more fields. In most cases, I'm looking for
> exact matches but sometimes an occasional wildcard query shows up too.
> Thank you!
>
> -- Martin
>
>
--
View this message in context:
http://www.nabble.com/fq-vs.-q-tp23845282p23847845.html
Sent from the Solr - User mailing list archive at Nabble.com.
I've tried to read up on how to decide, when writing a query, what
criteria goes in the q parameter and what goes in the fq parameter, to
achieve optimal performance. Is there some documentation that
describes how each field is treated internally, or even better, some
kind of rule of thumb
29 matches
Mail list logo
