the index is really representing?
: Am I right in assuming the Omit Norms flag in the Index row of the first
: picture is what is causing fieldNorm issues in the second image?
: If I am correct in the above question, how do I fix it?
>From a quick glance at the UI JavaScript c
e number of terms in it, yet
the fieldNorm is being set to 1.0 for matching 'supply' on the description
field. My guess is that the Omit Norms flag for the 'Index' row is causing
the issue.
Questions:
>From the first picture, can anyone tell me what each row (Properties,
On Jul 10, 2013, at 4:39 AM, Daniel Collins wrote:
> QueryNorm is what I'm still trying to get to the bottom of exactly :)
If you have not seen it, some reading from the past here…
https://issues.apache.org/jira/browse/LUCENE-1896
- Mark
Norms stay in the index even if you delete all of the data. If you just
changed the schema, emptied the index, and tested again, you've still
got norms in there.
You can examine the index with Luke to verify this.
On 07/09/2013 08:57 PM, William Bell wrote:
I have a field that has omit
Thanks.
Yeah I don't really want the queryNorm on
On Wed, Jul 10, 2013 at 2:39 AM, Daniel Collins wrote:
> I don't know the full answer to your question, but here's what I can offer.
>
> Solr offers 2 types of normalisation, FieldNorm and QueryNorm. FieldNorm
> is as the name suggests fiel
I don't know the full answer to your question, but here's what I can offer.
Solr offers 2 types of normalisation, FieldNorm and QueryNorm. FieldNorm
is as the name suggests field level normalisation, based on length of the
field, and can be controlled by the omitNorms parameter on the field. In
I have a field that has omitNorms=true, but when I look at debugQuery I see
that
the field is being normalized for the score.
What can I do to turn off normalization in the score?
I want a simple way to do 2 things:
boost geodist() highest at 1 mile and lowest at 100 miles.
plus add a boost for
On Sat, May 5, 2012 at 7:59 PM, Lance Norskog wrote:
> Which Similarity class do you use for the Lucene code? Solr has a custom one.
I am embarassed to report that I also have a custom similarity that I
didn't know about, and once I configured that into Solr all was well.
>
> On Fri, May 4, 201
Which Similarity class do you use for the Lucene code? Solr has a custom one.
On Fri, May 4, 2012 at 6:30 AM, Benson Margulies wrote:
> So, I've got some code that stores the same documents in a Lucene
> 3.5.0 index and a Solr 3.5.0 instance. It's only five documents.
>
> For a particular field,
So, I've got some code that stores the same documents in a Lucene
3.5.0 index and a Solr 3.5.0 instance. It's only five documents.
For a particular field, the Solr norm is always 0.625, while the
Lucene norm is .5.
I've watched the code in NormsWriterPerField in both cases.
In Solr we've got .57
e...@gmail.com [ysee...@gmail.com] On Behalf Of Yonik Seeley
[yo...@lucidimagination.com]
Sent: Thursday, November 10, 2011 10:22 PM
To: solr-user@lucene.apache.org
Subject: Re: [Solr-3.4] Norms file size is large in case of many unique indexed
fields in index
On Thu, Nov 10, 2011 at 7:42 AM, Ivan H
On Thu, Nov 10, 2011 at 7:42 AM, Ivan Hrytsyuk
wrote:
> For 5000 documents (every document has 2 unique fields, 2*5000=1
> unique fields in index), index size is 48.24 MB.
You might be able to turn this around and encode the "unique field"
information in a multi-valued field:
For example, in
We have large index size in case norms are enabled.
>
> schema.xml:
>
> type declaration:
> positionIncrementGap="100" omitNorms="false">
>
>
>
>
>
> fields declaration:
> type="string" />
>
> type=
Hello everyone,
We have large index size in case norms are enabled.
schema.xml:
type declaration:
fields declaration:
For 5000 documents (every document has 2 unique fields, 2*5000=1
unique fields in index), index size is 48.24 MB.
But if we enable omitting
Hi Ashmet,
You're right. It was related to the text field which is the defaultSearch
field. I also added omitNorms=true in the fieldtype definition and it's now
working as expected
Thanks,
Adolfo.
It seems that fieldNorm difference is coming from the field named 'text'. And
you didn't include the definition of text field. Did you omit norms for that
field too?
By the way I see that you have store="true" in some places but it should be
store*d*="true&
Hi All,
I hope someone could shed some light on the issue I'm facing with solr
3.1.0. It looks like it's computing diferrent fieldNorm values despite my
configuration that aims to ignore it.
I also have a custom class that extends DefaultSimilarity to override the
idf method.
Query:
Hi blargy,
Norms are:
- a field-specific multiplicative document scoring factor
- the product of three factors: user-settable 1) field boost and 2) document
boost (both default to 1.0), along with the 3) field length norm, defined in
DefaultSimilarity as 1/sqrt(# terms).
- encoded as a
Ok so as if I wanted to add boost to fields at indexing time then I should
include norms. On the other hand if I just want to boost at query time then
its quite alright to omit norms.
Anyone mind explaining what norms are in layman's terms ;)
Marc Sturlese wrote:
>
>>>Sho
>>Should I include not omit-norms on any fields that I would like to boost
via a boost-query/function >>query?
You don't have to set norms to use boost queries or functions. Just have to
set them when you want to boost docs or fields at indexing time.
>>What about sor
Should I include not omit-norms on any fields that I would like to boost via
a boost-query/function query?
For example I have a created_on field on one of my documents and I would
like to add some sort of function query to this field when querying. In this
case does this mean I need to have the
On 3/29/07, escher2k <[EMAIL PROTECTED]> wrote:
This is related to an earlier posting
(http://www.nabble.com/Document-boost-not-as-expected...-tf3476653.html).
I am trying to determine a ranking for users that is between 1 and 1.5.
Because of the way the encoding
norm is stored, if index time bo
or 1.5. Is there any way
to get around this so that all the values can be retrieved as is (e.g. 1.22,
1.35 etc).
Thanks in advance.
--
View this message in context:
http://www.nabble.com/Changing-encoding-norms-and-boosting...-tf3489245.html#a9744212
Sent from the Solr - User mailing list archive
23 matches
Mail list logo
