Re: docValues usage

And in the case of both stored=true and docValues=true, Solr 8.x shall be choosing the optimal approach by itself? On Wed, Nov 4, 2020 at 9:15 AM Wei wrote: > Thanks Erick. As indexed is not necessary, and docValues is more > efficient than stored fields for function queries, so we shall go w

Re: docValues usage

Thanks Erick. As indexed is not necessary, and docValues is more efficient than stored fields for function queries, so we shall go with the following: 3) indexed=false, stored=false, docValues=true. Is my understanding correct? Best, Wei On Wed, Nov 4, 2020 at 5:24 AM Erick Erickson wrot

Re: docValues usage

You don’t need to index the field for function queries, see: https://lucene.apache.org/solr/guide/8_6/docvalues.html. Function queries, as opposed to sorting, faceting and grouping are evaluated at search time where the search process is already parked on the document anyway, so answering the

Re: docValues usage

Hi, I'm by no means expert on this so if anyone sees a mistake please correct me. I think you need to index this field, since boost functions are added to the query as optional clauses (https://lucene.apache.org/solr/guide/6_6/the-dismax-query-parser.html#TheDisMaxQueryParser-Thebf_BoostFunctio

Re: DocValues or stored fields to enable atomic updates

Hi Andreas, Stored values are compressed so should take less disk. I am thinking that doc values might perform better when it comes to executing atomic update. HTH, Emir -- Monitoring - Log Management - Alerting - Anomaly Detection Solr & Elasticsearch Consulting Support Training - http://sematex

Re: docvalues set to true, and indexed is false and stored is set to false

Hi Ganesh, I cannot confirm for sure, but I would assume that it will not get reindexed, but just segments doc values file rewritten. It is best if you test this and see for yourself. Regards, Emir -- Monitoring - Log Management - Alerting - Anomaly Detection Solr & Elasticsearch Consulting Supp

Re: docvalues set to true, and indexed is false and stored is set to false

Hi Emir, Thanks for confirming that strField is not considered / available for in place updates. As per documentation, it says... *An atomic update operation is performed using this approach only when the fields to be updated meet these three conditions: are non-indexed (indexed="false"), non-

Re: docvalues set to true, and indexed is false and stored is set to false

Hi Ganesh, Doc values are enabled for strField and UUID but in place updates are not. It is not free = according to some discussions on mailing list (did not check the code) in place updates are not update of some value in doc values file but rewrite of doc values file for the segment that it is

Re: docvalues set to true, and indexed is false and stored is set to false

Hi, Thanks for clearing. But as per this link (Enabling DocValues) it says that it supports strField and UUID field also. Again, what you mean by it's not free for large segments. Can you point me to some d

Re: docvalues set to true, and indexed is false and stored is set to false

Hi, It is clearer now, but you mentioned strings in your first mail and in place updates only work for numeric fields. If you meet all conditions, document will not be reindexed, but only doc values rewritten for the segment where in place update happened. Note that this is not free for large se

Re: docvalues set to true, and indexed is false and stored is set to false

Hi, I guess my point is not conceived correctly. Here I am talking about the field "In Place Updates " As per above link, it says that complete document will not be re-indexed

Re: docvalues set to true, and indexed is false and stored is set to false

Whenever you send doc to indexing, it is indexed completely and old document with the same id (if one exists) is just flagged as deleted and will be removed from index when segment that it is stored is merged. In case of large segments, it might be never. The safest option is to do full reindex

Re: docvalues set to true, and indexed is false and stored is set to false

Hi, Thanks for quick response. I forgot to mention that after adding it, I have re-indexed all the data with dynamic fields Field_one, Field_two etc. In that case, by adding new field ( docvalue field ) or removing existing docvalue field, Will the whole document will re-indexed again, or only

Re: docvalues set to true, and indexed is false and stored is set to false

Hi, Changing schema will not do anything by itself. After changes are applied (core reloaded if not used API to update schema) it will use new schema to index new documents. What matters is what you had in index before schema updates. So if you had defined Field_one as string or you had it as nu

Re: docValues with stored and useDocValuesAsStored

Hi Bernd, If Solr can fetch a field from both stored and docValues then it chooses docValues only if such field is single-valued and that allows Solr to avoid accessing the stored document altogether for *all* fields to be returned. Otherwise stored values are preferred. This is the behavior since

Re: DocValues for multivalued strings and boolean fields

On 12/20/2017 6:09 PM, S G wrote: One of our Solr users is trying to set docValues="true" for multivalued string fields and boolean-type fields. I am not sure what the performance impact of that would be. Can docValues negatively affect performance in any way? Adding to what Emir said: The do

Re: DocValues for multivalued strings and boolean fields

Hi SG, Doc values is another file to write so indexing performances will suffer. In theory, query performances will suffer because alternative is in memory structure (fieldCache and fieldValueCache). In practice, it will not because in memory structure requires larger heap, requires time/resourc

Re: docValues

bq: ... using /select handler is the only solution to get data with fields other than docValues that I visualized. true, if it's not docValues then you need to do "something else", and /select works. bq: to allow the researcher to download the data so he can dive Ah, I understand now. I suspect

Re: docValues

Erick, thanks for explaining the memory aspects. Regarding the end user perspective, our intention is to provide a first layer of filtering, where data will be rolled up in some buckets and be displayed in charts and tables. When I told about provide access to "full" documents, it was not to displ

Re: docValues

Kojo: bq: My question is, isn´t it to expensive in terms of memory consumption to enable docValues on fields that I dont need to facet, search etc? Well, yes and no. The memory consumed is your OS memory space and a small bit of control structures on your Java heap. It's a bit scary that your _in

Re: docValues

I Think that I found the solution. After analysis, change from /export request handler to /select request handler in order to obtain other fields. I will try that. 2017-11-24 15:15 GMT-02:00 Kojo : > Thank you very much for your answer, Shawn. > > That is it, I was looking for another way to in

Re: docValues

Thank you very much for your answer, Shawn. That is it, I was looking for another way to include fields non docValues to the filtered result documents. I can enable docValues to other fields and reindex all if necessary. I will tell you about the use case, because I am not sure that I am on the r

Re: docValues

On 11/23/2017 1:51 PM, Kojo wrote: I am working on Solr to develop a toll to make analysis. I am using search function of Streaming Expressions, which requires a field to be indexed with docValues enabled, so I can get it. Suppose that after someone finishes the analysis, and would like to get o

Re: DocValues

Thank you Erick and Shawn. 1) So it seems like docValues should always be preferred over stored fields for retreival if sorting-of-multivalued-fields is not a concern. Is that a correct understanding? 2) Also, the in-place atomic updates (with docValues=true and stored/indexed=false) should be

Re: DocValues

I'll add that using docValues in place of stored is much more efficient than using stored. To access stored=true data 1> a 16K block must be read from disk 2> the 16K block must be decompressed. With docValues, the value is a simple lookup, the value is probably in memory already (MMapped) and the

Re: DocValues

On 11/17/2017 12:53 AM, S G wrote: Going through https://www.elastic.co/guide/en/elasticsearch/guide/current/_deep_dive_on_doc_values.html , is it possible to enable only docValues and disable stored/indexed attributes for a field? Yes, this is possible. In fact, if you want to do in-place Ato

Re: DocValues

Going through https://www.elastic.co/guide/en/elasticsearch/guide/current/_deep_dive_on_doc_values.html , is it possible to enable only docValues and disable stored/indexed attributes for a field? In that case, the field will become only sortable/facetable/pivotable but it cannot be searched nor c

Re: DocValues error when upgrading to 6.6.1 from 6.5

I have figured out the problem. The schema was changed and index has been deleted and rebuilt since then. But the index files might still contain the old stale segments. I replayed the situation by restoring the old data using 6.5, then do the optimization, then upgrade the 6.6.1, and found ou

Re: DocValues, Long and SolrJ

> > -Original Message- > From: Emir Arnautović [mailto:emir.arnauto...@sematext.com] > Sent: Tuesday, 26 September 2017 8:49 p.m. > To: solr-user@lucene.apache.org > Subject: Re: DocValues, Long and SolrJ > > Hi Phil, > Are you saying that you get this error when you

RE: DocValues, Long and SolrJ

ception ex) { } // start the index rebuild -Original Message- From: Phil Scadden [mailto:p.scad...@gns.cri.nz] Sent: Wednesday, 27 September 2017 10:04 a.m. To: solr-user@lucene.apache.org Subject: RE: DocValues, Long and SolrJ I get it after I have deleted the index with a delete query and start

RE: DocValues, Long and SolrJ

[mailto:emir.arnauto...@sematext.com] Sent: Tuesday, 26 September 2017 8:49 p.m. To: solr-user@lucene.apache.org Subject: Re: DocValues, Long and SolrJ Hi Phil, Are you saying that you get this error when you create fresh core/collection? This sort of errors are usually related to schema being

Re: DocValues, Long and SolrJ

Hi Phil, Are you saying that you get this error when you create fresh core/collection? This sort of errors are usually related to schema being changed after some documents being indexed. Thanks, Emir > On 25 Sep 2017, at 23:42, Phil Scadden wrote: > > I ran into a problem with indexing docume

Re: DocValues error when upgrading to 6.6.1 from 6.5

This error is not about DocValuesAsStored, but about multiValued=true|false. It indicates that multiValued is set to "false" for the current index but "true" in the new schema. At least that's my guess Best, Erick On Thu, Sep 21, 2017 at 11:56 AM, Xie, Sean wrote: > Hi, > > When I upgrade th

Error in Solr 6.6 Example schemas re: DocValues for StrField type must be single-valued?

Hello, The comments in the example schema's for Solr 6.6, for state that the StrField type must be single-valued to support doc values For example Solr-6.6.0/server/solr/configsets/basic_configs/conf/managed-schema: 216 However, on line 221 a StrField is declared with docValues that is mu

Re: DocValues and facet searches

It could be. Which version of Solr are you using ? Unfortunately I can not access your responses snippets, is it any exception in the logs ? Cheers -- View this message in context: http://lucene.472066.n3.nabble.com/DocValues-and-facet-searches-tp4317763p4317814.html Sent from the Solr - User

Re: docValues error

thanks Shawn, that seems to be the error exactly. On 02/29/2016 09:22 AM, Shawn Heisey wrote: On 2/28/2016 3:31 PM, David Santamauro wrote: I'm porting a 4.8 schema to 5.3 and I came across this new error when I tried to group.field=f1: unexpected docvalues type SORTED_SET for field 'f1' (ex

Re: docValues error

On 2/28/2016 3:31 PM, David Santamauro wrote: > > I'm porting a 4.8 schema to 5.3 and I came across this new error when > I tried to group.field=f1: > > unexpected docvalues type SORTED_SET for field 'f1' (expected=SORTED). > Use UninvertingReader or index with docvalues. > > f1 is defined as > >

Re: docValues error

On 02/29/2016 07:59 AM, Tom Evans wrote: On Mon, Feb 29, 2016 at 11:43 AM, David Santamauro wrote: You will have noticed below, the field definition does not contain multiValues=true What version of the schema are you using? In pre 1.1 schemas, multiValued="true" is the default if it is omi

Re: docValues error

On Mon, Feb 29, 2016 at 11:43 AM, David Santamauro wrote: > You will have noticed below, the field definition does not contain > multiValues=true What version of the schema are you using? In pre 1.1 schemas, multiValued="true" is the default if it is omitted. Cheers Tom

Re: docValues error

On 02/29/2016 06:05 AM, Mikhail Khludnev wrote: On Mon, Feb 29, 2016 at 12:43 PM, David Santamauro < david.santama...@gmail.com> wrote: unexpected docvalues type SORTED_SET for field 'f1' (expected=SORTED). Use UninvertingReader or index with docvalues. DocValues is primary citizen api f

Re: docValues error

On Mon, Feb 29, 2016 at 12:43 PM, David Santamauro < david.santama...@gmail.com> wrote: > > So I started over (deleted all documents), re-deployed configs to > zookeeper and reloaded the collection. > > This error still appears when I group.field=f1 > > unexpected docvalues type SORTED_SET for fie

Re: docValues error

So I started over (deleted all documents), re-deployed configs to zookeeper and reloaded the collection. This error still appears when I group.field=f1 unexpected docvalues type SORTED_SET for field 'f1' (expected=SORTED). Use UninvertingReader or index with docvalues. What exactly does th

Re: docValues error

David, this is tad weird. I've seen this error if you turn on docvalues for an existing field. You can running an "optimize" on your index and see if it helps. -- View this message in context: http://lucene.472066.n3.nabble.com/docValues-error-tp4260408p4260455.html Sent from the Solr - User ma

Re: DocValues error

Ugh! I totally missed the highlight. Thanks for clarifying. On 11/13/15, 1:07 PM, "Anshum Gupta" wrote: >Hi Devansh, > >Yes you'd need to reindex your data in order to use DocValues. It's >highlighted here @ the official ref guide : > >https://cwiki.apache.org/confluence/display/solr/DocVa

Re: DocValues error

Hi Devansh, Yes you'd need to reindex your data in order to use DocValues. It's highlighted here @ the official ref guide : https://cwiki.apache.org/confluence/display/solr/DocValues On Fri, Nov 13, 2015 at 10:00 AM, Dhutia, Devansh wrote: > We have an existing collection with a field called l

Re: docValues

Json Nested faceting on string,string,double fields. Facet function 'sum' is applied on double field Without docValue response for the same query 1) First response without cache 765 Ms 2) second response with cache 28 Ms 3) third response with cache 78 Ms 4) fourth response with cache 94 Ms With

Re: docValues

Interesting... what type of field was this? (string or numeric? single or multi-valued?) Without docValues, the first request would be slow (due to building the in-memory field cache entry), but after that it should be fast. -Yonik On Sun, Aug 9, 2015 at 11:31 AM, Nagasharath wrote: > I Have t

Re: docValues

I Have tested with docValue and without docValue on the test indexes with a json nested faceting query. Have noticed performance boot with the docValue.The response time with Cached items and without cached items is good. I have noticed that the response time on the cached items of the index wi

Re: docValues

Have you seen: https://cwiki.apache.org/confluence/display/solr/DocValues? What kind of speedup? How often are you committing? Is there a speed difference after a while or on the first few queries? Details matter a lot for questions like this. Best, Erick On Sat, Aug 8, 2015 at 6:22 PM, Nagasha

Re: docValues

Good Sent from my iPhone > On 08-Aug-2015, at 8:12 pm, Aman Tandon wrote: > > Hi, > > >> I am seeing a significant difference in the query time after using docValue > > what kind of difference, is it good or bad? > > With Regards > Aman Tandon > > On Sat, Aug 8, 2015 at 11:38 PM, Nagashara

Re: docValues

Hi, > I am seeing a significant difference in the query time after using docValue what kind of difference, is it good or bad? With Regards Aman Tandon On Sat, Aug 8, 2015 at 11:38 PM, Nagasharath wrote: > I am seeing a significant difference in the query time after using > docValue. > > I am

Re: docValues

I am seeing a significant difference in the query time after using docValue. I am curious to know what's happening with 'docValue' included in the schema > On 07-Aug-2015, at 4:31 pm, Shawn Heisey wrote: > >> On 8/7/2015 11:47 AM, naga sharathrayapati wrote: >> JVM-Memory has gone up from 3% to

Re: docValues

On 8/7/2015 11:47 AM, naga sharathrayapati wrote: > JVM-Memory has gone up from 3% to 17.1% In my experience, a healthy Java application (after the heap size has stabilized) will have a heap utilization graph where the low points are between 50 and 75 percent. If the low points in heap utilizatio

Re: docValues

JVM-Memory has gone up from 3% to 17.1% On Fri, Aug 7, 2015 at 12:10 PM, Shawn Heisey wrote: > On 8/7/2015 10:25 AM, naga sharathrayapati wrote: > > i have added docValues="true" to my existing schema and I have seen > > exponential increase in the size of the index. > > > > The reason in going

Re: docValues

On 8/7/2015 10:25 AM, naga sharathrayapati wrote: > i have added docValues="true" to my existing schema and I have seen > exponential increase in the size of the index. > > The reason in going with docValues is to improve the faceting query time. > > schema: > multiValued="false" docValues="true"/

Re: docValues

My crude approximation is that docValues increases the disk size, but that's mostly due to serializing data that would be built in-memory, basically serializing these structures. So while they increase disk size, the memory requirements aren't increased. AFAIK, the in-memory size is a bit smaller a

Re: DocValues: Which format is better Default or Memory?

So should I use Memory format? With Regards Aman Tandon On Thu, Jul 2, 2015 at 9:20 PM, Toke Eskildsen wrote: > Alessandro Benedetti wrote: > > DocValues is a strategy to store on the disk ( or in memory) the > > Un-inverted index for the field of interests. > > True. > > > This has been done

Re: DocValues: Which format is better Default or Memory?

Alessandro Benedetti wrote: > DocValues is a strategy to store on the disk ( or in memory) the > Un-inverted index for the field of interests. True. > This has been done to SPEED UP the faceting calculus using the "fc" > algorithm, and improve the memory usage. Part of the reason was to speed u

Re: DocValues: Which format is better Default or Memory?

How are you testing? I'd do a couple of things: 1> turn of your queryResultCache (set its size to 0). 2> run multiple queries through something like jmeter 3> insure you've run enough warmup queries to load all your fields into memory. Basically, if this were always the case, I'd expect a _lo

Re: DocValues: Which format is better Default or Memory?

Anything wrong? With Regards Aman Tandon On Thu, Jul 2, 2015 at 4:19 PM, Aman Tandon wrote: > Hi, > > I tried to query the without and with docValues, the query with docValues > was taking more time. Does it may be due to IO got involved as some data > will be in some file. > > Are you sure any

Re: DocValues: Which format is better Default or Memory?

Hi, I tried to query the without and with docValues, the query with docValues was taking more time. Does it may be due to IO got involved as some data will be in some file. Are you sure anything else could affect your times ? Yes I am sure. We re-indexed the whole index of 40 Million records, t

Re: DocValues: Which format is better Default or Memory?

So first of all, DocValues is a strategy to store on the disk ( or in memory) the Un-inverted index for the field of interests. This has been done to SPEED UP the faceting calculus using the "fc" algorithm, and improve the memory usage. It is really weird that this is the cause of a degrading of pe

Re: DocValues memory consumption thoughts

m DocValues actually is an un-inverted index that is built as part of the segment. This means that it has the same behaviour of the other segments files. Assuming you are indexing not a compound segment file but a classic multi filed segment in a NRTCachingDirectory, The segment is built in mem

Re: docValues in solr/lucene 4.8.x

I would like to add this , to Shawn description : DocValues are only available for specific field types. The types chosen > determine the underlying Lucene docValue type that will be used. The > available Solr field types are: > >- StrField and UUIDField. >- If the field is single-valued (

Re: docValues in solr/lucene 4.8.x

On 6/4/2015 11:42 PM, pras.venkatesh wrote: > I see docValues has been there since Lucene 4.0. so can I use docValues with > my current solr cloud version of 4.8.x > > The reason I am asking is because, I have deployment mechanism and securing > the index (using Tomcat valve) all built out based

Re: docValues: Can we apply synonym

t; > >> > > > http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/ > > > > >> > > > > > >> > -Original Message- > > > > >> > From: Aman Tandon [mailto:amantandon...@gmail.com] > > > &

Re: docValues: Can we apply synonym

lem. > > > >> > > > >> With Regards > > > >> Aman Tandon > > > >> > > > >> On Fri, May 29, 2015 at 12:38 AM, Reitzel, Charles < > > > >> charles.reit...@tiaa-cref.org> wrote: > > > >> > > >

Re: docValues: Can we apply synonym

charles.reit...@tiaa-cref.org> wrote: > > >> > > >> > Again, I would recommend using Nolan Lawson's > > >> > SynonymExpandingExtendedDismaxQParserPlugin. > > >> > > > >> > http://nolanlawson.com/2012/10/31/better-synonym

Re: docValues: Can we apply synonym

's > >> > SynonymExpandingExtendedDismaxQParserPlugin. > >> > > >> > http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/ > >> > > >> > -Original Message- > >> > From: Aman Tandon [mailto:amantandon...@gma

Re: docValues: Can we apply synonym

ttp://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/ >> > >> > -Original Message- >> > From: Aman Tandon [mailto:amantandon...@gmail.com] >> > Sent: Wednesday, May 27, 2015 6:42 PM >> > To: solr-user@lucene.apache.org >> > Subje

Re: docValues: Can we apply synonym

> > -Original Message- > > From: Aman Tandon [mailto:amantandon...@gmail.com] > > Sent: Wednesday, May 27, 2015 6:42 PM > > To: solr-user@lucene.apache.org > > Subject: Re: docValues: Can we apply synonym > > > > Ok and what synonym processor you is

Re: docValues: Can we apply synonym

rPlugin. > > http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/ > > -Original Message- > From: Aman Tandon [mailto:amantandon...@gmail.com] > Sent: Wednesday, May 27, 2015 6:42 PM > To: solr-user@lucene.apache.org > Subject: Re: docValues: Can we apply

RE: docValues: Can we apply synonym

-user@lucene.apache.org Subject: Re: docValues: Can we apply synonym Ok and what synonym processor you is talking about maybe it could help ? With Regards Aman Tandon On Thu, May 28, 2015 at 4:01 AM, Reitzel, Charles < charles.reit...@tiaa-cref.org> wrote: > Sorry, my bad. The synon

Re: docValues: Can we apply synonym

on of the EDisMax query processor and doesn't require field level > synonym configs. > > -Original Message- > From: Reitzel, Charles [mailto:charles.reit...@tiaa-cref.org] > Sent: Wednesday, May 27, 2015 6:12 PM > To: solr-user@lucene.apache.org > Subject: RE: docVal

RE: docValues: Can we apply synonym

15 6:12 PM To: solr-user@lucene.apache.org Subject: RE: docValues: Can we apply synonym But the query analysis isn't on a specific field, it is applied to the query string. -Original Message- From: Aman Tandon [mailto:amantandon...@gmail.com] Sent: Wednesday, May 27, 2015 6:08 P

RE: docValues: Can we apply synonym

But the query analysis isn't on a specific field, it is applied to the query string. -Original Message- From: Aman Tandon [mailto:amantandon...@gmail.com] Sent: Wednesday, May 27, 2015 6:08 PM To: solr-user@lucene.apache.org Subject: Re: docValues: Can we apply synonym Hi Charles,

Re: docValues: Can we apply synonym

versa. > Haven't tried it with docValues, tho. > > -Original Message- > From: Aman Tandon [mailto:amantandon...@gmail.com] > Sent: Tuesday, May 26, 2015 11:15 PM > To: solr-user@lucene.apache.org > Subject: Re: docValues: Can we apply synonym > > Yes it could

RE: docValues: Can we apply synonym

docValues, tho. -Original Message- From: Aman Tandon [mailto:amantandon...@gmail.com] Sent: Tuesday, May 26, 2015 11:15 PM To: solr-user@lucene.apache.org Subject: Re: docValues: Can we apply synonym Yes it could be :) Anyway thanks for helping. With Regards Aman Tandon On Tue, May 26

Re: docValues: Can we apply synonym

Yes it could be :) Anyway thanks for helping. With Regards Aman Tandon On Tue, May 26, 2015 at 10:22 PM, Alessandro Benedetti < benedetti.ale...@gmail.com> wrote: > I should investigate that, as usually synonyms are analysis stage. > A simple way is to replace the word with all its synonyms ( i

Re: docValues: Can we apply synonym

I should investigate that, as usually synonyms are analysis stage. A simple way is to replace the word with all its synonyms ( including original word), but simply using this kind of processor will change the token position and offsets, modifying the actual content of the document . " I am from Bo

Re: docValues: Can we apply synonym

Okay So how could I do it with UpdateProcessors? With Regards Aman Tandon On Tue, May 26, 2015 at 10:00 PM, Alessandro Benedetti < benedetti.ale...@gmail.com> wrote: > mmm this is different ! > Without any customisation, right now you could : > - use docValues to provide exact value facets. > -

Re: docValues: Can we apply synonym

mmm this is different ! Without any customisation, right now you could : - use docValues to provide exact value facets. - Than you can use a copy field, with the proper analysis, to search when a user click on a filter ! So you will see in your facets : Mumbai(3) Bombay(2) And when clicking you s

Re: docValues: Can we apply synonym

We are interested in using docValues for better memory utilization and speed. Currently we are faceting the search results on *city. *In city we have also added the synonym for cities like mumbai, bombay (These are Indian cities). So that result of mumbai is also eligible when somebody will applyi

Re: docValues: Can we apply synonym

I checked in the Documentation to be sure, but apparently : DocValues are only available for specific field types. The types chosen determine the underlying Lucene docValue type that will be used. The available Solr field types are: - StrField and UUIDField. - If the field is single-valued

Re: docValues: Can we apply synonym

To my understanding, docValues are just an uninverted index. That is, it contains the terms that are generated at the end of an analysis chain. Therefore, you simply enable docValues and include the SynonymFilterFactory in your analysis. Is that enough, or are you struggling with some other issue?

Re: DocValues="true" and indexed="false"

Yes, surprisingly enough, if indexed=false, docValues=true — you can still search. I’ve seen the code behind it; it’s interesting. Rob wrote it. I’m not sure how scalable it is compared to the inverted index. I suspect it wouldn’t do well for a lot of distinct values but will fine for a small nu

Re: DOcValues

Thank you. This is very understandable. I heard the Strings limitation for DocValues goes away in 5.0? On Fri, Apr 3, 2015 at 2:35 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > On Fri, Apr 3, 2015 at 12:52 PM, Toke Eskildsen > wrote: > > > Shalin Shekhar Mangar wrote: > > > The

Re: DOcValues

On Fri, Apr 3, 2015 at 12:52 PM, Toke Eskildsen wrote: > Shalin Shekhar Mangar wrote: > > The UnInvertedField method of faceting is no longer used in Solr. > > True. Un-inversion still takes place for non-DV-fields though (see > UnivertingReader, which seems to lead to > FieldCacheImpl.SortedDoc

Re: DOcValues

Shalin Shekhar Mangar wrote: > The UnInvertedField method of faceting is no longer used in Solr. True. Un-inversion still takes place for non-DV-fields though (see UnivertingReader, which seems to lead to FieldCacheImpl.SortedDocValuesCache). But the wrapping is far nicer as everything looks li

Re: DOcValues

Sorry I should have been more clear. The UnInvertedField method of faceting is not used in Solr since Solr 5.0. On Fri, Apr 3, 2015 at 12:17 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > The UnInvertedField method of faceting is no longer used in Solr. > > See https://issues.apache

Re: DOcValues

The UnInvertedField method of faceting is no longer used in Solr. See https://issues.apache.org/jira/browse/SOLR-7190 On Fri, Apr 3, 2015 at 10:33 AM, Toke Eskildsen wrote: > William Bell wrote: > > [docValues activation?] > > > Also, does it help with "*Too many values for UnInvertedField fac

Re: DOcValues

William Bell wrote: [docValues activation?] > Also, does it help with "*Too many values for UnInvertedField faceting" ?* Yes. There is an internal limit using UnInverted (aka fc without docValues) of 16M somewhere - I am not sure exactly what it takes to trigger it, but many unique values and

Re: DOcValues

Dear Shawn, Thank you for the detailed explanation! Many users would need such guidelines about memory consumption (and performance trade-offs) for facets. Thanks, Tomoko 2015-04-03 22:26 GMT+09:00 Shawn Heisey : > On 4/3/2015 6:53 AM, Tomoko Uchida wrote: > > According to line 430 in SImpleFac

Re: DOcValues

On 4/3/2015 6:53 AM, Tomoko Uchida wrote: > According to line 430 in SImpleFacet.java (Solr 5.0.0), facet method is > forced to "fc" when we set docValues=true. > https://github.com/apache/lucene-solr/blob/lucene_solr_5_0_0/solr/core/src/java/org/apache/solr/request/SimpleFacets.java#L430 > > So w

Re: DOcValues

Hi, According to line 430 in SImpleFacet.java (Solr 5.0.0), facet method is forced to "fc" when we set docValues=true. https://github.com/apache/lucene-solr/blob/lucene_solr_5_0_0/solr/core/src/java/org/apache/solr/request/SimpleFacets.java#L430 So we need not set facet.method to use doc values.

Re: DocValues without re-index?

On 7/22/2014 6:14 AM, Michael Ryan wrote: > I mean re-adding all of the documents in my index. The DocValues wiki page > says that this is necessary, but I wanted to know if there was a way around > it. If your index meets the strict criteria for Atomic Updates, you could "update" all the docume

RE: DocValues without re-index?

: solr-user Subject: Re: DocValues without re-index? Michael, What's "first re-indexing"? I'm sure you are aware about binary/number DocValues updates, but it works for existing column strides. I can guess you are talking about something like sidecar index http://www.youtube.com

Re: DocValues without re-index?

Michael, What's "first re-indexing"? I'm sure you are aware about binary/number DocValues updates, but it works for existing column strides. I can guess you are talking about something like sidecar index http://www.youtube.com/watch?v=9h3ax5Wmxpk On Tue, Jul 22, 2014 at 6:50 AM, Michael Ryan w

Re: DocValues and StatsComponent

Hi Harish, I created https://issues.apache.org/jira/browse/SOLR-6024 on behalf of you. Ahmet On Friday, April 4, 2014 3:13 AM, Ahmet Arslan wrote: Hi Harish, I re-produced your problem with example/default setup. I enabled doc values example fields. ( deleted the original ones) and indexed

Re: DocValues and StatsComponent

Hi Harish, I re-produced your problem with example/default setup. I enabled doc values example fields. ( deleted the original ones) and indexed example documents.       Single valued fields work fine. But stats on multi-valued field cat yields  http://localhost:8983/solr/collection1/select?q=

  1   2   >