Invalid version in nightly builds of AI 2.x

[Ivan Daschinsky]

Hi folks!

Recently I've discovered that nightly builds are generated with invalid
version
Namely 3.0.0.x instead of 2.12.0.x.
The main reason -- recent changes in maven pom's.
I've filled ticket [1] and described thoroughly what should be fixed.

Peter, could you take a look?

[1] -- https://issues.apache.org/jira/browse/IGNITE-15768

Re: Invalid version in nightly builds of AI 2.x

[Petr Ivanov]

Hi. Ivan.


Thanks!
I will attend to the issue in nearest time.

> On 22 Oct 2021, at 12:25, Ivan Daschinsky  wrote:
> 
> Hi folks!
> 
> Recently I've discovered that nightly builds are generated with invalid 
> version
> Namely 3.0.0.x instead of 2.12.0.x.
> The main reason -- recent changes in maven pom's. 
> I've filled ticket [1] and described thoroughly what should be fixed.
> 
> Peter, could you take a look?
> 
> [1] -- https://issues.apache.org/jira/browse/IGNITE-15768 
> 

Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]

[Nikolay Izhikov]

Hello.

In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the following API 
are prepared:

1. MVCC 
- https://issues.apache.org/jira/browse/IGNITE-15757 
- https://github.com/apache/ignite/pull/9516

2. LOCAL caches 
- https://issues.apache.org/jira/browse/IGNITE-15756 
- https://github.com/apache/ignite/pull/9515

3. CacheConfiguration#rebalanceDelay 
- https://issues.apache.org/jira/browse/IGNITE-15764 
- https://github.com/apache/ignite/pull/9515

Please, review.


> 21 окт. 2021 г., в 20:33, Nikita Amelchev  написал(а):
> 
> Petr, thank you!
> 
> чт, 21 окт. 2021 г. в 18:19, Petr Ivanov :
>> 
>> Try now, please.
>> 
>>> On 21 Oct 2021, at 17:47, Nikita Amelchev  wrote:
>>> 
>>> Hi,
>>> 
>>> Petr, could you grant me TC permissions to run release builds please?
>>> 
>>> ср, 20 окт. 2021 г. в 10:25, Pavel Tupitsyn :
>>> 
 
 Igniters,
 
 I've filed a blocker - release configurations on TeamCity should be fixed
 after recent .NET project structure refactoring:
 https://issues.apache.org/jira/browse/IGNITE-15779
 
 I'm on vacation right now with limited internet access, I'll work on this
 ASAP next week.
 
 On Wed, Oct 13, 2021 at 2:33 PM Nikita Amelchev 
 wrote:
 
> Igniters,
> 
> Scope freeze is planned for Friday, October 15.
> I suggest creating the release branch on that date.
> 
> The wiki page with the release info. [1] Please, check the fix version
> of your issues.
> 
> There are no unresolved blockers.
> There are 3 important issues in the review state. [2]
> 
> Also, please, pay attention to unresolved documentation issues. [3]
> 
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.12
> [2]
> https://issues.apache.org/jira/issues/?jql=(resolution%20%3D%20Unresolved%20AND%20project%20%3D%20%27Ignite%27%20AND%20type%20in%20(%22New%20Feature%22%2C%20Task%2C%20Sub-task%2C%20Improvement)%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20AND%20(labels%20in%20(%27important%27)%20OR%20Flags%20%3D%20Important))%20order%20by%20summary
> [3]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20status%20NOT%20IN%20(Resolved%2C%20Closed)%20AND%20component%20in%20(documentation)%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20
> 
> пт, 1 окт. 2021 г. в 19:06, Pavel Tupitsyn :
>> 
>> I'm working on IGNITE-15504 and plan to finish it early next week.
>> 
>> On Fri, Oct 1, 2021 at 6:08 PM Nikita Amelchev 
> wrote:
>> 
>>> Igniters,
>>> 
>>> I have created the wiki page for the 2.12 release. [1]
>>> 
>>> The release scope contains 1 issue that is marked as a blocker:
>>> IGNITE-15504 .NET: SDK 2.1 is out of support, make sure project can be
>>> developed with newer SDKs [2]
>>> 
>>> Folks, do not forget to document features (65 issues still not
> resolved).
>>> [3]
>>> 
>>> Maxim, Ivan,
>>> +1 to add these issues to the 2.12 scope.
>>> 
>>> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.12
>>> [2] https://issues.apache.org/jira/browse/IGNITE-15504
>>> [3]
>>> 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20status%20NOT%20IN%20(Resolved%2C%20Closed)%20AND%20component%20in%20(documentation)%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20
>>> 
>>> ср, 29 сент. 2021 г. в 11:28, Ivan Daschinsky :
 
 Created issues related building ODBC module, running C++ suites and
 removing VS project files
 
 1. https://issues.apache.org/jira/browse/IGNITE-15637
 2.https://issues.apache.org/jira/browse/IGNITE-15636
 
 вс, 26 сент. 2021 г. в 19:50, Ivan Daschinsky :
 
> +1
> 
> Let's consider building odbc driver using Visual C++ 2017?
> 
> 2015, 2017 and 2019 share the same redistributable package and it
> is
>>> the
> default one in Windows 10.
> 
> Also, let's remove vs project files, since the most of you all
> agree
>>> that
> it is redundant.
> 
> If both suggestions are ok, I will create ticketa soon.
> 
> вс, 26 сент. 2021 г., 17:10 Pavel Tupitsyn :
> 
>> +1
>> 
>> On Fri, Sep 24, 2021 at 8:04 PM Maxim Muzafarov <
> mmu...@apache.org>
>> wrote:
>> 
>>> Hello Nikita,
>>> 
>>> +1 if you will lead this release.
>>> 
>>> 
>>> I'd suggest including into the release scope this one issue too:
>>> 
>>> Snapshot restore m

Re: [DISCUSSION][IEP-80] Breaking changes in Ignite-2.x

[Nikolay Izhikov]

Hello.

In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the following API 
are prepared:

1. MVCC 
- https://issues.apache.org/jira/browse/IGNITE-15757 
- https://github.com/apache/ignite/pull/9516

2. LOCAL caches 
- https://issues.apache.org/jira/browse/IGNITE-15756 
- https://github.com/apache/ignite/pull/9515

3. CacheConfiguration#rebalanceDelay 
- https://issues.apache.org/jira/browse/IGNITE-15764 
- https://github.com/apache/ignite/pull/9515

Please, review.

> 15 окт. 2021 г., в 16:23, Nikolay Izhikov  написал(а):
> 
> THanks, Maksim.
> 
> Tickets included in IEP scope and marked for d&r in 2.12-2.13
> 
>> 15 окт. 2021 г., в 16:03, Maxim Muzafarov  написал(а):
>> 
>> Let's deprecate RebalanceDelay and RebalanceMode=NONE also.
>> 
>> [1] https://issues.apache.org/jira/browse/IGNITE-12662
>> [2] https://issues.apache.org/jira/browse/IGNITE-14613
>> 
>> On Fri, 15 Oct 2021 at 15:46, Anton Vinogradov  wrote:
>>> 
>>> +1
>>> 
>>> On Fri, Oct 15, 2021 at 3:41 PM Nikita Amelchev 
>>> wrote:
>>> 
 +1 for deprecation in the 2.12 release
 
 пт, 15 окт. 2021 г. в 15:35, Nikolay Izhikov :
> 
> Hello, Igniters.
> 
> I’ve prepared IEP-80 [1] to track breaking changes that should be done
 in Ignite 2.x.
> 
> We agreed on the following algorithm to deal with breaking changes:
> 
>   - Ignite 2.[x] - deprecate the API + notification of the users.
>   - Ignite 2.[x+1] - API removal.
> 
> 
> I propose to start these improvements with the d&r (depuration &
 removal) of the following features:
> 
>   - LOCAL caches
>   - MVCC caches
>   - legacy service grid implementation
>   - legacy JMX metrics beans.
> 
> Deprecation in 2.12
> Removal in 2.13
> 
> Please, share your opinion.
> 
> [1]
 https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=191334475
 
 
 
 --
 Best wishes,
 Amelchev Nikita
 
> 

Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]

[Nikita Amelchev]

Igniters,

Could you help with the TC bot configuration?

The TC bot should be configured to the `ignite-2.12` release branch.

пт, 22 окт. 2021 г. в 12:42, Nikolay Izhikov :
>
> Hello.
>
> In the scope of IEP-80 Breaking changes in Ignite-2.x PR for the following 
> API are prepared:
>
> 1. MVCC
> - https://issues.apache.org/jira/browse/IGNITE-15757
> - https://github.com/apache/ignite/pull/9516
>
> 2. LOCAL caches
> - https://issues.apache.org/jira/browse/IGNITE-15756
> - https://github.com/apache/ignite/pull/9515
>
> 3. CacheConfiguration#rebalanceDelay
> - https://issues.apache.org/jira/browse/IGNITE-15764
> - https://github.com/apache/ignite/pull/9515
>
> Please, review.
>
>
> > 21 окт. 2021 г., в 20:33, Nikita Amelchev  написал(а):
> >
> > Petr, thank you!
> >
> > чт, 21 окт. 2021 г. в 18:19, Petr Ivanov :
> >>
> >> Try now, please.
> >>
> >>> On 21 Oct 2021, at 17:47, Nikita Amelchev  wrote:
> >>>
> >>> Hi,
> >>>
> >>> Petr, could you grant me TC permissions to run release builds please?
> >>>
> >>> ср, 20 окт. 2021 г. в 10:25, Pavel Tupitsyn :
> >>>
> 
>  Igniters,
> 
>  I've filed a blocker - release configurations on TeamCity should be fixed
>  after recent .NET project structure refactoring:
>  https://issues.apache.org/jira/browse/IGNITE-15779
> 
>  I'm on vacation right now with limited internet access, I'll work on this
>  ASAP next week.
> 
>  On Wed, Oct 13, 2021 at 2:33 PM Nikita Amelchev 
>  wrote:
> 
> > Igniters,
> >
> > Scope freeze is planned for Friday, October 15.
> > I suggest creating the release branch on that date.
> >
> > The wiki page with the release info. [1] Please, check the fix version
> > of your issues.
> >
> > There are no unresolved blockers.
> > There are 3 important issues in the review state. [2]
> >
> > Also, please, pay attention to unresolved documentation issues. [3]
> >
> > [1] 
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.12
> > [2]
> > https://issues.apache.org/jira/issues/?jql=(resolution%20%3D%20Unresolved%20AND%20project%20%3D%20%27Ignite%27%20AND%20type%20in%20(%22New%20Feature%22%2C%20Task%2C%20Sub-task%2C%20Improvement)%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20(component%20is%20EMPTY%20OR%20component%20not%20in%20(documentation))%20AND%20(labels%20in%20(%27important%27)%20OR%20Flags%20%3D%20Important))%20order%20by%20summary
> > [3]
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20status%20NOT%20IN%20(Resolved%2C%20Closed)%20AND%20component%20in%20(documentation)%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20
> >
> > пт, 1 окт. 2021 г. в 19:06, Pavel Tupitsyn :
> >>
> >> I'm working on IGNITE-15504 and plan to finish it early next week.
> >>
> >> On Fri, Oct 1, 2021 at 6:08 PM Nikita Amelchev 
> > wrote:
> >>
> >>> Igniters,
> >>>
> >>> I have created the wiki page for the 2.12 release. [1]
> >>>
> >>> The release scope contains 1 issue that is marked as a blocker:
> >>> IGNITE-15504 .NET: SDK 2.1 is out of support, make sure project can be
> >>> developed with newer SDKs [2]
> >>>
> >>> Folks, do not forget to document features (65 issues still not
> > resolved).
> >>> [3]
> >>>
> >>> Maxim, Ivan,
> >>> +1 to add these issues to the 2.12 scope.
> >>>
> >>> [1]
> > https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+2.12
> >>> [2] https://issues.apache.org/jira/browse/IGNITE-15504
> >>> [3]
> >>>
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20%27Ignite%27%20AND%20fixVersion%20is%20not%20empty%20AND%20fixVersion%20in%20(%272.12%27)%20AND%20status%20NOT%20IN%20(Resolved%2C%20Closed)%20AND%20component%20in%20(documentation)%20ORDER%20BY%20priority%20%20%20%20%20%20%20%20%20
> >>>
> >>> ср, 29 сент. 2021 г. в 11:28, Ivan Daschinsky :
> 
>  Created issues related building ODBC module, running C++ suites and
>  removing VS project files
> 
>  1. https://issues.apache.org/jira/browse/IGNITE-15637
>  2.https://issues.apache.org/jira/browse/IGNITE-15636
> 
>  вс, 26 сент. 2021 г. в 19:50, Ivan Daschinsky :
> 
> > +1
> >
> > Let's consider building odbc driver using Visual C++ 2017?
> >
> > 2015, 2017 and 2019 share the same redistributable package and it
> > is
> >>> the
> > default one in Windows 10.
> >
> > Also, let's remove vs project files, since the most of you all
> > agree
> >>> that
> > it is redundant.
> >
> > If both suggestions are ok, I will create ticketa soon.
> >
> > вс, 26 сент. 2021 г., 17:10 Pavel Tupitsyn :
>

Re: [DISCUSS] Custom service proxy context

[Pavel Pereslegin]

> 1. Add init/execute/cancel methods without parameters.
> 2. Add default no-op implementations for the new methods (this is required
> to preserve compatibility).
> 3. For old methods that take ServiceContext as a parameter, add default
> implementations that delegate to new methods.
> 4. Deprecate the old methods on the API.
> 5. On the implementation level, still use the old methods (again - for
> compatibility).
> 6. Finally, add a @ServiceContextResource annotation to inject
> ServiceContext.

I like this idea and I have filed a ticket for this change [1].
If there is no objection, I plan to implement this shortly.

[1] https://issues.apache.org/jira/browse/IGNITE-15801

ср, 20 окт. 2021 г. в 08:54, Nikolay Izhikov :
>
> > and it fully switches to annotation-based injection.
>
> +1 to do it.
>
> > 19 окт. 2021 г., в 22:14, Valentin Kulichenko 
> >  написал(а):
> >
> > That's actually a good point. In Java, we can do the following:
> > 1. Add init/execute/cancel methods without parameters.
> > 2. Add default no-op implementations for the new methods (this is required
> > to preserve compatibility).
> > 3. For old methods that take ServiceContext as a parameter, add default
> > implementations that delegate to new methods.
> > 4. Deprecate the old methods on the API.
> > 5. On the implementation level, still use the old methods (again - for
> > compatibility).
> > 6. Finally, add a @ServiceContextResource annotation to inject
> > ServiceContext.
> >
> > If I haven't missed anything, this is not a breaking change, and it fully
> > switches to annotation-based injection.
> >
> > I'm not sure this is possible in .NET though.
> >
> > -Val
> >
> > On Tue, Oct 19, 2021 at 11:47 AM Pavel Pereslegin  wrote:
> >
> >>> Removing parameters from a public interface method is a breaking change,
> >>> or do you mean something else?
> >>
> >> Sorry, I meant that we can inject the service context, but leave it
> >> available in the init/execute/cancel methods and add a default "no-op"
> >> implementation in the interface for them. Can we do this?
> >>
> >>> Regarding .NET - let's have a separate ticket for that?
> >> If we decide to "inject" a service context - this should be done in a
> >> separate ticket.
> >> If you are talking about "proxy service context" - I can split it into
> >> 3 parts (java, Net, and thin clients)
> >>
> >> вт, 19 окт. 2021 г. в 21:23, Pavel Tupitsyn :
> >>>
> >>> Pavel,
> >>>
>  From my point of view, this should not break anything
> >>> Removing parameters from a public interface method is a breaking change,
> >>> or do you mean something else?
> >>>
> >>> Regarding .NET - let's have a separate ticket for that?
> >>> We can discuss and implement Java changes first.
> >>>
> >>> On Tue, Oct 19, 2021 at 8:27 PM Pavel Pereslegin 
> >> wrote:
> >>>
>  Thanks a lot for your suggestions.
> 
> > We might consider injecting the ServiceContext instead of passing it
> >> to
> > IgniteService methods, but I believe this will be a breaking change?
> 
>  From my point of view, this should not break anything. We can inject a
>  service context when initializing a service and keep it accessible in
>  state transition methods (init/execute/cancel).
>  Currently, in .Net ServiceContext doesn't share the same instance, but
>  this can be reworked - for example, we can store the service context
>  (with a reference to the service) in the resource registry instead of
>  the service itself.
> 
>  But I don't see much usability improvement with such a feature if the
>  user still needs to implement state transition methods. I think it
>  would be nice to add default "no-op" implementations for them.
>  Unfortunately, we are currently unable to do the same in .Net because
>  such a feature is not supported in C# 4.0 (it's available in C# 8.0).
> 
>  Can we add default "no-op" implementations for init/execute/cancel
>  methods in Java and leave them unchanged in .Net?
> 
>  вт, 19 окт. 2021 г. в 18:51, Valentin Kulichenko
>  :
> >
> > I support #2, because we already have the ServiceContext. Having
> > both ServiceContext and @ServiceRequestContextResource that injects
> >> some
> > function (or any other mechanism for that matter) will be VERY
> >> confusing.
> > Let's keep it simple.
> >
> > At the same time, I do agree with Nikolay that injection is the
> >> approach
> > taken across the platform, so I'm not sure why we are not using it
> >> here.
>  We
> > might consider injecting the ServiceContext instead of passing it to
> > IgniteService methods, but I believe this will be a breaking change?
> >
> > -Val
> >
> > On Tue, Oct 19, 2021 at 4:49 AM Ivan Daschinsky  >>>
>  wrote:
> >
> >> I am for limiting types of attributes values only to UTF-8 strings
> >> and
> >> bytearrays.
> >> Also, I agree with Pavel, (2) is clear and without an

A new feedback has been added : 24

[Bugyard]

A new feedback has been added, go to bugyard.io to see all the details...

https://bugyard.io

A new feedback has been added 

"Link is not working"   by utkarshkbhavsar 

View feedback 
https://app.bugyard.io/web/app/rycqZJDyY/f/61725cc577102f0014717688

Re: Re: Apache Ignite 2.12 RELEASE [Time, Scope, Manager]

[Сергей Утцель]

I configured TC bot to 'ignite-2.12' instead of 'ignite-2.11'

Re: Text Queries Support

[Maximiliano Gazquez]

Hello everyone!

I wanted to add this to the discussion.
I've found this project https://github.com/hawkore/ignite-hk which promises
to solve most of the issues that are being discussed here like pagination,
sorting and most important, persisting the lucene index.

It does stuff like this to create indexes:

CREATE INDEX PERSON_LUCENE_IDX ON "PUBLIC".PERSON(LUCENE)
FULLTEXT '{
''refresh_seconds'':''60'',
''directory_path'':,
''ram_buffer_mb'':''10'',
''max_cached_mb'':''-1'',
''partitioner'':''{"type":"token","partitions":10}'',
''optimizer_enabled'':''true'',
''optimizer_schedule'':''0 1 * * *'',
''version'':''0'',
''schema'':''{
"default_analyzer":"english",

"analyzers":{"my_custom_analyzer":{"type":"snowball","language":"Spanish","stopwords":"el,la,lo,loas,las,a,ante,bajo,cabe,con,contra"}},
"fields":{

"duration":{"type":"date_range","from":"start_date","to":"stop_date","validated":false,"pattern":"/MM/dd"},

"place":{"type":"geo_point","latitude":"latitude","longitude":"longitude"},
  "date":{"type":"date","validated":true,"pattern":"/MM/dd"},
  "number":{"type":"integer","validated":false,"boost":1.0},
  "gender":{"type":"string","validated":true,"case_sensitive":true},
  "bool":{"type":"boolean","validated":false},

"phrase":{"type":"text","validated":false,"analyzer":"my_custom_analyzer"},
  "name":{"type":"string","validated":false,"case_sensitive":true},
  "animal":{"type":"string","validated":false,"case_sensitive":true},
  "age":{"type":"integer","validated":false,"boost":1.0},
  "food":{"type":"string","validated":false,"case_sensitive":true}
}
  }''
}';

And this to use that lucene index from inside SQL:

SELECT * FROM "test".user
WHERE lucene = '{ query : {
  type : "boolean",
  must : [{type : "wildcard", field : "name",
value : "J*"},
  {type : "wildcard", field : "food",
value : "tu*"}]}}';

More examples here
https://github.com/hawkore/examples-apache-ignite-extensions/tree/master/examples-advanced-ignite-indexing

I don't have anything to do with that company but it would be great to know
how they implemented this stuff.


On Mon, Aug 9, 2021 at 3:00 AM Ivan Pavlukhin  wrote:

> Hi Atri,
>
> Sorry for a late answer.
>
> > I didn't quite understand. Are you proposing that Ignite should not have
> FTS capabilities?
>
> It seems an option to me. IMHO it is better to have no FTS instead of
> something like current Ignite TextQueries.
>
> 2021-08-03 12:45 GMT+03:00, Atri Sharma :
> > Hi Ivan,
> >
> > I didn't quite understand. Are you proposing that Ignite should not
> > have FTS capabilities?
> >
> > Atri
> >
> > On Tue, Aug 3, 2021 at 2:57 PM Ivan Pavlukhin 
> wrote:
> >>
> >> Hi Atri,
> >>
> >> My main concern is non-maleficence. Every task has several solutions,
> >> e.g. straightforward ones:
> >> 1. Do not implement FTS.
> >> 2. Create own implementation.
> >>
> >> Some of the strongest ones live without FTS [1].
> >>
> >> [1] https://github.com/cockroachdb/cockroach/issues/7821
> >>
> >> 2021-08-02 11:33 GMT+03:00, Atri Sharma :
> >> > Hi Ivan,
> >> >
> >> > Would you like to propose an alternative to Lucene?
> >> >
> >> > Atri
> >> >
> >> > On Mon, 2 Aug 2021, 13:48 Ivan Pavlukhin, 
> wrote:
> >> >
> >> >> Folks,
> >> >>
> >> >> Sorry if read the thread not thoroughly enough, but do we consider
> >> >> Lucene as obviously right choice? In my understanding Ignite history
> >> >> has shown clearly that "fastest feature implementation" is not
> usually
> >> >> the best. And one example of this are text queries. Are not we trying
> >> >> to do a same mistake again? FTS is a huge feature, I do not believe
> >> >> there is an easy win for it.
> >> >>
> >> >> 2021-07-27 19:18 GMT+03:00, Atri Sharma :
> >> >> > Andrey,
> >> >> >
> >> >> >> Per-partition Lucene index looks simple to implement, but it may
> >> >> >> require
> >> >> >> per-partition SQL to make full-text search expressions work
> >> >> >> correctly
> >> >> >> within the SQL quiery.
> >> >> > I think that as long as we follow the map - reduce process that we
> >> >> > already do for other queries, we should be fine.
> >> >> >
> >> >> >> Per-partition SQL index may kill the performance. We already tried
> >> >> >> to
> >> >> >> do
> >> >> >> that in Ignite 2. However, QueryParallelism feature helps to speed
> >> >> >> up
> >> >> >> some
> >> >> >> data-intensive queries,
> >> >> >> but hits the performance in simple cases, and at some point (e.g.
> >> >> >> segments
> >> >> >> > number of CPU) the performance rapidly degrades with the
> >> >> >> > increasing
> >> >> >> number of segments.
> >> >> >
> >> >> > Yeah, that is always the case, but a global index will be a
> >> >> > nightmare
> >> >> > in terms of concurrency and pessimistic concurrency control will
> >> >> > anyways kill the benefits, coupled with the metadata requirements.
> >> >> > What were the specific issues with per