On 8/1/2013 8:31 AM, Kuchekar wrote:
> Hi,
>
> Are there any changes in Solr 4.4 version in regards to Stored fields
> compression, compared to Solr 4.1.
>
> My understanding is that Solr 4.1 by default provides compression of stored
> fields compared to Solr 4.0 and its earlier versions.
Hi,
Are there any changes in Solr 4.4 version in regards to Stored fields
compression, compared to Solr 4.1.
My understanding is that Solr 4.1 by default provides compression of stored
fields compared to Solr 4.0 and its earlier versions.
Please correct me if my understanding is wrong.
Th
Von: Shawn Heisey [s...@elyograg.org]
Gesendet: Donnerstag, 24. Januar 2013 16:58
An: solr-user@lucene.apache.org
Betreff: Re: Does solr 4.1 support field compression?
On 1/24/2013 8:42 AM, Ken Prows wrote:
> I didn't see any mention of field compression in the relea
On 1/24/2013 8:42 AM, Ken Prows wrote:
I didn't see any mention of field compression in the release notes for
Solr 4.1. Did the ability to automatically compress fields end up
getting added to this release?
The concept of compressed fields (an option in schema.xml) that existed
in th
__
> Von: Rafał Kuć [r@solr.pl]
> Gesendet: Donnerstag, 24. Januar 2013 16:45
> An: solr-user@lucene.apache.org
> Betreff: Re: Does solr 4.1 support field compression?
>
> Hello!
>
> It should be turned on by default, because the stored fields
> compressio
ost/33247161884/efficient-compressed-stored-fields-with-lucene)"
André
Von: Rafał Kuć [r@solr.pl]
Gesendet: Donnerstag, 24. Januar 2013 16:45
An: solr-user@lucene.apache.org
Betreff: Re: Does solr 4.1 support field compression?
Hello!
It should be
Hello!
It should be turned on by default, because the stored fields
compression is the behavior of the default Lucene 4.1 codec.
--
Regards,
Rafał Kuć
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - ElasticSearch
> Hi everyone,
> I didn't see any mention of field com
Hi everyone,
I didn't see any mention of field compression in the release notes for
Solr 4.1. Did the ability to automatically compress fields end up
getting added to this release?
Thanks!,
Ken
On 5/23/2012 2:48 PM, pramila_tha...@ontla.ola.org wrote:
Hi Everyone,
solr 3.6 does not seem to be honoring the field compress.
While merging the indexes the size of Index is very big.
Is there any other way to handle this to keep compression functionality?
Compression support was removed
/field-compression-in-solr-3-6-tp3985780.html
Sent from the Solr - User mailing list archive at Nabble.com.
see when I get to it.
~ David Smiley
Author: http://www.packtpub.com/solr-1-4-enterprise-search-server/
On Apr 15, 2011, at 12:56 PM, Charlie Jackson wrote:
> I know I'm late to the party, but I recently learned that field compression
> was removed as of Solr 1.4.1. I think a lot of sites
I know I'm late to the party, but I recently learned that field compression was
removed as of Solr 1.4.1. I think a lot of sites were relying on that feature,
so I'm curious what people are doing now that it's gone. Specifically, what are
people doing to efficiently store *and h
Fer-Bj schrieb:
for all the documents we have a field called "small_body" , which is a
60 chars max text field that were we store the "abstract" for each
article.
we need to display this small_body we want to compress every time.
If this works like compressing individual files, the overhead
Lucene itself
>> has lazy field loading that helps in this case, but I don't know how
>> to persuade SOLR to use it (it may even lazy-load automatically).
>> But this is separate from searching...
>
> Lazy loading is an option configured in the solrconfig.xml
>
>
&
On Jun 4, 2009, at 6:42 AM, Erick Erickson wrote:
It *will* cause performance issues if you load that field for a large
number of documents on a particular search. I know Lucene itself
has lazy field loading that helps in this case, but I don't know how
to persuade SOLR to use it (it may even
9 at 4:07 AM, Fer-Bj wrote:
>
> Is it correct to assume that using field compression will cause performance
> issues if we decide to allow search over this field?
>
> ie:
>
> required="true" />
> omitNorms="true"/>
>stored="true&q
Is it correct to assume that using field compression will cause performance
issues if we decide to allow search over this field?
ie:
if I decide to add "compressed=true" to the BODY field... and a I allow
search on body... would that be a problem?
At the same time
On 24-Jun-08, at 4:26 PM, Chris Harris wrote:
I have an index that I eventually want to rebuild so I can set
compressed=true on a couple of fields. It's not really practical to
rebuild
the whole thing right now, though. If I change my schema.xml to set
compressed=true and then keep adding ne
I have an index that I eventually want to rebuild so I can set
compressed=true on a couple of fields. It's not really practical to rebuild
the whole thing right now, though. If I change my schema.xml to set
compressed=true and then keep adding new data to the existing index, will
this corrupt the i
processed is
great for memory/CPU cache usage.
http://youtube.com/watch?v=yrLd-3lnZ58
While interesting, its not relevant to Lucene's stored field
storage. On the other hand, it did get me thinking about stored
field compression and lazy field loading.
Can anyone give me some pointers
.
http://youtube.com/watch?v=yrLd-3lnZ58
While interesting, its not relevant to Lucene's stored field storage. On the
other hand, it did get me thinking about stored field compression and lazy
field loading.
Can anyone give me some pointers about compressThreshold values that would be
21 matches
Mail list logo
