Re: Committing `CASSANDRA-13701 Lower default num_tokens` and the dtest slowdown…
Thanks Adam. Now that we have CASSANDRA-16079 created and work is proceeding, can we please commit CASSANDRA-13701? There are many clusters out there that use the default of 256 num_tokens and migrating to something more sane is a lot of work. It would also be very helpful for having reasonable defaults getting tested for the release. It's been a bad default for a long, long time and we need to get this in before we do more testing for the release. > On Aug 28, 2020, at 5:25 AM, Adam Holmberg wrote: > > After discussing with a few stakeholders it sounds like folks agree that > optimizing dtest speed is a worthy endeavor. What is less clear are > concrete things that should be done. Since a brainstorming session failed > to materialize on CASSANDRA-13701, we thought it would make sense to start > with an open analysis. > > A ticket[1] has been created for analysis and further follow-up. We welcome > any concrete ideas people already have in mind. > > Kind regards, > Adam Holmberg > > [1] https://issues.apache.org/jira/browse/CASSANDRA-16079 > > On Mon, Aug 24, 2020 at 12:17 PM Mick Semb Wever wrote: > >> I believe the speed of our CI runs >>> is of common interest. What do you think? Does this sound feasible? Who >> is >>> in?* >>> >> >> >> I agree. I'm in. I have some ideas to add to the mix. Thanks Ekaterina. >> > > > -- > Adam Holmberg > e. adam.holmb...@datastax.com > w. www.datastax.com - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On 2/9/20 5:09, Joshua McKenzie wrote: > +1 > > On Tue, Sep 1, 2020 at 6:26 PM Jordan West wrote: > >> +1 >> >> On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith < >> bened...@apache.org> >> wrote: >> >>> +1 >>> >>> >>> >>> On 01/09/2020, 20:09, "Caleb Rackliffe" >> wrote: >>> >>> >>> +1 >>> >>> >>> >>> On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < >>> jasonstack.z...@gmail.com> >>> >>> wrote: >>> >>> >>> >>> > +1 >>> >>> > >>> >>> > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi >> wrote: >>> > >>> >>> > > +1 >>> >>> > > >>> >>> > > > On Sep 1, 2020, at 11:27 AM, David Capwell >> >>> wrote: >>> >>> > > > >>> >>> > > > Currently our style guide recommends to avoid using @Override >> and >>> > updates >>> >>> > > > intellij's code style to exclude it by default; I would like to >>> propose >>> >>> > > we >>> >>> > > > change this recommendation to use it and to update intellij's >>> style to >>> >>> > > > include it by default. >>> >>> > > > >>> >>> > > > @Override is used by javac to enforce that a method is in fact >>> >>> > overriding >>> >>> > > > from an abstract class or an interface and if this stops being >>> true >>> >>> > (such >>> >>> > > > as a refactor happens) then a compiler error is thrown; when we >>> default >>> >>> > > to >>> >>> > > > excluding, it makes it harder to detect that a refactor catches >>> all >>> >>> > > > implementations and can lead to subtle and hard to track down >>> bugs. >>> >>> > > > >>> >>> > > > This proposal is for new code and would not be to go rewrite >> all >>> code >>> >>> > at >>> >>> > > > once, but would recommend new code adopt this style, and to >> pull >>> old >>> >>> > code >>> >>> > > > forward which is related to changes being made (similar to our >>> stance >>> >>> > on >>> >>> > > > imports). >>> >>> > > > >>> >>> > > > If people are ok with this, I will file a JIRA, update the >> docs, >>> and >>> >>> > > > update intellij's formatting. >>> >>> > > > >>> >>> > > > Thanks for your time! >>> >>> > > >>> >>> > > >>> >>> > > >>> - >>> >>> > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> >>> > > For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> > > >>> >>> > > >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> - >>> >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >>> >>> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Tue, Sep 1, 2020 at 6:26 PM Jordan West wrote: > +1 > > On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > +1 > > > > > > > > On 01/09/2020, 20:09, "Caleb Rackliffe" > wrote: > > > > > > > > +1 > > > > > > > > On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < > > jasonstack.z...@gmail.com> > > > > wrote: > > > > > > > > > +1 > > > > > > > > > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi > wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell > > > wrote: > > > > > > > > > > > > > > Currently our style guide recommends to avoid using @Override > and > > > > > updates > > > > > > > intellij's code style to exclude it by default; I would like to > > propose > > > > > > we > > > > > > > change this recommendation to use it and to update intellij's > > style to > > > > > > > include it by default. > > > > > > > > > > > > > > @Override is used by javac to enforce that a method is in fact > > > > > overriding > > > > > > > from an abstract class or an interface and if this stops being > > true > > > > > (such > > > > > > > as a refactor happens) then a compiler error is thrown; when we > > default > > > > > > to > > > > > > > excluding, it makes it harder to detect that a refactor catches > > all > > > > > > > implementations and can lead to subtle and hard to track down > > bugs. > > > > > > > > > > > > > > This proposal is for new code and would not be to go rewrite > all > > code > > > > > at > > > > > > > once, but would recommend new code adopt this style, and to > pull > > old > > > > > code > > > > > > > forward which is related to changes being made (similar to our > > stance > > > > > on > > > > > > > imports). > > > > > > > > > > > > > > If people are ok with this, I will file a JIRA, update the > docs, > > and > > > > > > > update intellij's formatting. > > > > > > > > > > > > > > Thanks for your time! > > > > > > > > > > > > > > > > > > > > - > > > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Tue, Sep 1, 2020 at 12:22 PM Benedict Elliott Smith wrote: > +1 > > > > On 01/09/2020, 20:09, "Caleb Rackliffe" wrote: > > > > +1 > > > > On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang < > jasonstack.z...@gmail.com> > > wrote: > > > > > +1 > > > > > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > > > > > +1 > > > > > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell > wrote: > > > > > > > > > > Currently our style guide recommends to avoid using @Override and > > > updates > > > > > intellij's code style to exclude it by default; I would like to > propose > > > > we > > > > > change this recommendation to use it and to update intellij's > style to > > > > > include it by default. > > > > > > > > > > @Override is used by javac to enforce that a method is in fact > > > overriding > > > > > from an abstract class or an interface and if this stops being > true > > > (such > > > > > as a refactor happens) then a compiler error is thrown; when we > default > > > > to > > > > > excluding, it makes it harder to detect that a refactor catches > all > > > > > implementations and can lead to subtle and hard to track down > bugs. > > > > > > > > > > This proposal is for new code and would not be to go rewrite all > code > > > at > > > > > once, but would recommend new code adopt this style, and to pull > old > > > code > > > > > forward which is related to changes being made (similar to our > stance > > > on > > > > > imports). > > > > > > > > > > If people are ok with this, I will file a JIRA, update the docs, > and > > > > > update intellij's formatting. > > > > > > > > > > Thanks for your time! > > > > > > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On 01/09/2020, 20:09, "Caleb Rackliffe" wrote: +1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's code style to exclude it by default; I would like to propose > > we > > > change this recommendation to use it and to update intellij's style to > > > include it by default. > > > > > > @Override is used by javac to enforce that a method is in fact > overriding > > > from an abstract class or an interface and if this stops being true > (such > > > as a refactor happens) then a compiler error is thrown; when we default > > to > > > excluding, it makes it harder to detect that a refactor catches all > > > implementations and can lead to subtle and hard to track down bugs. > > > > > > This proposal is for new code and would not be to go rewrite all code > at > > > once, but would recommend new code adopt this style, and to pull old > code > > > forward which is related to changes being made (similar to our stance > on > > > imports). > > > > > > If people are ok with this, I will file a JIRA, update the docs, and > > > update intellij's formatting. > > > > > > Thanks for your time! > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 From: Caleb Rackliffe Sent: Tuesday, September 1, 2020 12:08:50 PM To: dev@cassandra.apache.org Subject: Re: [DISCUSS] Change style guide to recommend use of @Override +1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's code style to exclude it by default; I would like to propose > > we > > > change this recommendation to use it and to update intellij's style to > > > include it by default. > > > > > > @Override is used by javac to enforce that a method is in fact > overriding > > > from an abstract class or an interface and if this stops being true > (such > > > as a refactor happens) then a compiler error is thrown; when we default > > to > > > excluding, it makes it harder to detect that a refactor catches all > > > implementations and can lead to subtle and hard to track down bugs. > > > > > > This proposal is for new code and would not be to go rewrite all code > at > > > once, but would recommend new code adopt this style, and to pull old > code > > > forward which is related to changes being made (similar to our stance > on > > > imports). > > > > > > If people are ok with this, I will file a JIRA, update the docs, and > > > update intellij's formatting. > > > > > > Thanks for your time! > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang wrote: > +1 > > On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > > > +1 > > > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > > > Currently our style guide recommends to avoid using @Override and > updates > > > intellij's code style to exclude it by default; I would like to propose > > we > > > change this recommendation to use it and to update intellij's style to > > > include it by default. > > > > > > @Override is used by javac to enforce that a method is in fact > overriding > > > from an abstract class or an interface and if this stops being true > (such > > > as a refactor happens) then a compiler error is thrown; when we default > > to > > > excluding, it makes it harder to detect that a refactor catches all > > > implementations and can lead to subtle and hard to track down bugs. > > > > > > This proposal is for new code and would not be to go rewrite all code > at > > > once, but would recommend new code adopt this style, and to pull old > code > > > forward which is related to changes being made (similar to our stance > on > > > imports). > > > > > > If people are ok with this, I will file a JIRA, update the docs, and > > > update intellij's formatting. > > > > > > Thanks for your time! > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote: > +1 > > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > > > Currently our style guide recommends to avoid using @Override and updates > > intellij's code style to exclude it by default; I would like to propose > we > > change this recommendation to use it and to update intellij's style to > > include it by default. > > > > @Override is used by javac to enforce that a method is in fact overriding > > from an abstract class or an interface and if this stops being true (such > > as a refactor happens) then a compiler error is thrown; when we default > to > > excluding, it makes it harder to detect that a refactor catches all > > implementations and can lead to subtle and hard to track down bugs. > > > > This proposal is for new code and would not be to go rewrite all code at > > once, but would recommend new code adopt this style, and to pull old code > > forward which is related to changes being made (similar to our stance on > > imports). > > > > If people are ok with this, I will file a JIRA, update the docs, and > > update intellij's formatting. > > > > Thanks for your time! > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: [DISCUSS] Change style guide to recommend use of @Override
+1 > On Sep 1, 2020, at 11:27 AM, David Capwell wrote: > > Currently our style guide recommends to avoid using @Override and updates > intellij's code style to exclude it by default; I would like to propose we > change this recommendation to use it and to update intellij's style to > include it by default. > > @Override is used by javac to enforce that a method is in fact overriding > from an abstract class or an interface and if this stops being true (such > as a refactor happens) then a compiler error is thrown; when we default to > excluding, it makes it harder to detect that a refactor catches all > implementations and can lead to subtle and hard to track down bugs. > > This proposal is for new code and would not be to go rewrite all code at > once, but would recommend new code adopt this style, and to pull old code > forward which is related to changes being made (similar to our stance on > imports). > > If people are ok with this, I will file a JIRA, update the docs, and > update intellij's formatting. > > Thanks for your time! - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
[DISCUSS] Change style guide to recommend use of @Override
Currently our style guide recommends to avoid using @Override and updates intellij's code style to exclude it by default; I would like to propose we change this recommendation to use it and to update intellij's style to include it by default. @Override is used by javac to enforce that a method is in fact overriding from an abstract class or an interface and if this stops being true (such as a refactor happens) then a compiler error is thrown; when we default to excluding, it makes it harder to detect that a refactor catches all implementations and can lead to subtle and hard to track down bugs. This proposal is for new code and would not be to go rewrite all code at once, but would recommend new code adopt this style, and to pull old code forward which is related to changes being made (similar to our stance on imports). If people are ok with this, I will file a JIRA, update the docs, and update intellij's formatting. Thanks for your time!
Re: cassandra.logdir
Go for it!
On Mon, Aug 31, 2020 at 10:23 PM Cyril Scetbon
wrote:
> Hey guys,
>
> Experimenting with Cassandra 4.0 I’m seeing that when CASSANDRA_LOG_DIR is
> set and ${cassandra.logdir} is used in logback.xml nodetool doesn’t use the
> env variable. It’s different for cassandra for instance
> https://github.com/apache/cassandra/blob/324267b3c0676ad31bd4f2fac0e2e673a9257a37/bin/cassandra#L186
> <
> https://github.com/apache/cassandra/blob/324267b3c0676ad31bd4f2fac0e2e673a9257a37/bin/cassandra#L186>.
> I feel like it should be added to
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/bin/nodetool
> <
> https://github.com/apache/cassandra/blob/06209037ea56b5a2a49615a99f1542d6ea1b2947/bin/nodetool>,
> any objection to creating a ticket to do it ?
>
> Thanks
> —
> Cyril
>
>
Re: Problem in updating schema in Cassandra 3.11.4
I’m reasonably certain that this is one of the things that I fixed in 4.0. It’d be too invasive a change for 3.11, unfortunately. > On 1 Sep 2020, at 16:52, Benjamin Lerer wrote: > > Hi, > > Could you precise what you mean by " will only validate the schema while > changing in memory, and will not validate before flush to disk.". It is > unclear to me of which validation you are talking about. > > > > > > On Tue, Sep 1, 2020 at 1:44 PM Weiliang Zhang <394693...@qq.com> wrote: > >> Does anyone has any ideas? >> >> On 2020/08/31 10:07:30, weiliang zhang<394693...@qq.com> wrote: >>> Hi everyone, I found that cassandra will first flush new schema to disk >> and then change in memory while updating schema in Cassandra3.11.4 >> (SchemaKeyspace.java:1378) . >>> But it seems that cassandra will only validate the schema while changing >> in memory, and will not validate before flush to disk. >>> I don't know why not validate before flushing to disk ? Some request >> will succeed in updating schema to disk and fail to update schema in >> memory, which will make the schema in disk and schema in memory are not >> consistent. >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: dev-h...@cassandra.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org >> For additional commands, e-mail: dev-h...@cassandra.apache.org >> >> - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability
CVE-2020-13946 Apache Cassandra RMI Rebind Vulnerability Versions Affected: All versions prior to: 2.1.22, 2.2.18, 3.0.22, 3.11.8 and 4.0-beta2 Description: It is possible for a local attacker without access to the Apache Cassandra process or configuration files to manipulate the RMI registry to perform a man-in-the-middle attack and capture user names and passwords used to access the JMX interface. The attacker can then use these credentials to access the JMX interface and perform unauthorised operations. Users should also be aware of CVE-2019-2684, a JRE vulnerability that enables this issue to be exploited remotely. Mitigation: 2.1.x users should upgrade to 2.1.22 2.2.x users should upgrade to 2.2.18 3.0.x users should upgrade to 3.0.22 3.11.x users should upgrade to 3.11.8 4.0-beta1 users should upgrade to 4.0-beta2
Re: Problem in updating schema in Cassandra 3.11.4
Does anyone has any ideas? On 2020/08/31 10:07:30, weiliang zhang<394693...@qq.com> wrote: > Hi everyone, I found that cassandra will first flush new schema to disk and > then change in memory while updating schema in Cassandra3.11.4 > (SchemaKeyspace.java:1378) . > But it seems that cassandra will only validate the schema while changing in > memory, and will not validate before flush to disk. > I don't know why not validate before flushing to disk ? Some request will > succeed in updating schema to disk and fail to update schema in memory, which > will make the schema in disk and schema in memory are not consistent. > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] CEP-7 Storage Attached Index
Thank you, Charles and Patrick On Tue, 1 Sep 2020 at 04:56, Charles Cao wrote: > Thank you, Patrick! > > On Mon, Aug 31, 2020 at 12:59 PM Patrick McFadin > wrote: > > > > I just moved it to 8AM for this meeting to better accommodate APAC. > Please > > see the update here: > > > https://cwiki.apache.org/confluence/display/CASSANDRA/2020-08-01+Apache+Cassandra+Contributor+Meeting > > > > Patrick > > > > On Mon, Aug 31, 2020 at 10:04 AM Charles Cao > wrote: > > > > > Patrick, > > > > > > 11AM PST is a bad time for the people in the APAC timezone. Can we > > > move it to 7 or 8AM PST in the morning to accommodate their needs ? > > > > > > ~Charles > > > > > > On Fri, Aug 28, 2020 at 4:37 PM Patrick McFadin > > > wrote: > > > > > > > > Meeting scheduled. > > > > > > > > https://cwiki.apache.org/confluence/display/CASSANDRA/2020-08-01+Apache+Cassandra+Contributor+Meeting > > > > > > > > Tuesday September 1st, 11AM PST. I added a basic bullet for the > agenda > > > but > > > > if there is more, edit away. > > > > > > > > Patrick > > > > > > > > On Thu, Aug 27, 2020 at 11:31 AM Jasonstack Zhao Yang < > > > > jasonstack.z...@gmail.com> wrote: > > > > > > > > > +1 > > > > > > > > > > On Thu, 27 Aug 2020 at 04:52, Ekaterina Dimitrova < > > > e.dimitr...@gmail.com> > > > > > wrote: > > > > > > > > > > > +1 > > > > > > > > > > > > On Wed, 26 Aug 2020 at 16:48, Caleb Rackliffe < > > > calebrackli...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > +1 > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Aug 26, 2020, 3:45 PM Patrick McFadin < > pmcfa...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This is related to the discussion Jordan and I had about the > > > > > > contributor > > > > > > > > > > > > > > > Zoom call. Instead of open mic for any issue, call it based > on a > > > > > > > discussion > > > > > > > > > > > > > > > thread or threads for higher bandwidth discussion. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I would be happy to schedule on for next week to specifically > > > discuss > > > > > > > > > > > > > > > CEP-7. I can attach the recorded call to the CEP after. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > +1 or -1? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Patrick > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 25, 2020 at 7:03 AM Joshua McKenzie < > > > > > jmcken...@apache.org> > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Does community plan to open another discussion or CEP on > > > > > > > > > > > > > > > modularization? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We probably should have a discussion on the ML or monthly > > > contrib > > > > > > call > > > > > > > > > > > > > > > > about it first to see how aligned the interested > contributors > > > are. > > > > > > > Could > > > > > > > > > > > > > > > do > > > > > > > > > > > > > > > > that through CEP as well but CEP's (at least thus far sans > k8s > > > > > > > operator) > > > > > > > > > > > > > > > > tend to start with a strong, deeply thought out point of > view > > > being > > > > > > > > > > > > > > > > expressed. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Aug 25, 2020 at 3:26 AM Jasonstack Zhao Yang < > > > > > > > > > > > > > > > > jasonstack.z...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> SASI's performance, specifically the search in the B+ > > > tree > > > > > > > > > > > > > > > component, > > > > > > > > > > > > > > > > > >>> depends a lot on the component file's header being > > > available > > > > > in > > > > > > > the > > > > > > > > > > > > > > > > > >>> pagecache. SASI benefits from (needs) nodes with > lots of > > > RAM. > > > > > > Is > > > > > > > > > > > > > > > SAI > > > > > > > > > > > > > > > > > bound > > > > > > > > > > > > > > > > > >>> to this same or similar limitation? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > SAI also benefits from larger memory because SAI puts > block > > > info > > > > > on > > > > > > > > > > > > > > > heap > > > > > > > > > > > > > > > > > for searching on-disk components and having cross-index > > > files on > > > > > > page > > > > > > > > > > > > > > > > cache > > > > > > > > > > > > > > > > > improves read performance of different indexes on the > same > > > table. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >>> Flushing of SASI can be CPU+IO intensive, to the > point of > > > > > > > > > > > > > > > saturation, > > > > > > > > > > > > > > > > > >>> pauses, and crashes on the node. SSDs are a must, > along > > > with > > > > > a > > > > > > > bit > > > > > > > > > > > > > > > of > > > > > > > > > > > > > > > > > >>> tuning, just to avoid bringing down your cluster. > Beyond > > > >
