Hi,
> I'd really, really like to see us ship a Prom compatible metrics endpoint
out of the box in C* that has low overhead. All the current OSS metrics
exporters that I've seen have massive overhead. I'm specifically looking
for sub-10s collection on clusters with a thousand nodes and 500+ table
but there are valid secondary uses of the commit log that
> > are served well enough by the current architecture.
> >
> > It is important, however, to let the memtable implementation opt out,
> > to permit it to provide its own solution for data persistence.
> >
&
Hi,
It is nice to see these going forward (and a great use of CEP) so thanks
for the proposal. I have my reservations regarding the linking of memtable
to CommitLog and flushing and should not leak abstraction from one to
another. And I don't see the reasoning why they should be, it doesn't seem
t
;>>>> being raised. The rules for arithmetic are generally governed
> by
> >>>>> Subclause 6.12, "".
> >>>>> "
> >>>>>
> >>>>> Section 6.12 numeric value expressions:
> >>>>>
On 11/12/18 5:37 PM, Michael Shuler wrote:
Issue with upstream links to:
https://github.com/hyperic/sigar/issues/77
.. clip. Considering the Sigar has been unmaintained for years (and has
large amount of unfixed bugs), should we consider removing it from the
project? It's not used much, so fi
Hi,
I'm not sure if I would prefer the Postgres way of doing things, which is
returning just about any type depending on the order of operators.
Considering it actually mentions in the docs that using numeric/decimal is
slow and also multiple times that floating points are inexact. So doing
some m
On 07/12/2018 07:38 PM, Stefan Podkowinski wrote:
this point? Also, if we tell someone that their contribution will be
reviewed and committed later after 4.0-beta, how is that actually making
a difference for that person, compared to committing it now for a 4.x
version. It may be satisfying to ge
2018/06/01 07:40:04, Michael Burman wrote:
IIRC, there's no major distribution yet that defaults to Python 3 (I
think Ubuntu & Debian are still defaulting to Python 2 also). This will
happen eventually (maybe), but not yet. Discarding Python 2 support
would mean more base-OS work for most
Hi,
Should definitely be cross compatible with Python 2/3. Most of the
systems (such as those running on RHEL7 or distros based on it like
CentOS) are shipping with 2.7 only by default. And these systems are
probably going to be used for a long time to run Cassandra.
IIRC, there's no major d
On 03/21/2018 04:52 PM, Josh McKenzie wrote:
This would certainly mitigate a lot of the core problems with the new
release model. Has there been any public statements of plans/intent
with regards to distros doing this?
Since the latest official LTS version is Java 8, that's the only one
with pu
2:25 AM, Nate McCall wrote:
Hi Micke,
There is some good research in here - have you had a chance to create
some issues in Jira from this?
On Fri, Feb 23, 2018 at 6:28 AM, Michael Burman wrote:
Hi,
I was referring to this article by Shipilev (there are few small issues
forgotten in that url
or changes to how we do threading in 4.0. It's probably also worth
opening a JIRA and investigating the calls to nano time. We at least need
microsecond resolution here, and there could be something we haven't thought
of? It's worth a look at least.
Thanks,
Blake
On 2/22/18,
o how we do threading in
4.0. It's probably also worth opening a JIRA and investigating the calls to
nano time. We at least need microsecond resolution here, and there could be
something we haven't thought of? It's worth a look at least.
Thanks,
Blake
On 2/22/18, 6:10 AM, "M
Hi,
I wanted to get some input from the mailing list before making a JIRA
and potential fixes. I'll touch the performance more on latter part, but
there's one important question regarding the write latency metric
recording place. Currently we measure the writeLatency (and metric write
sampler
Hi,
There's a ticket also for columnar storage option, which I guess is
something that many might want. Not least because in many cases it could
reduce the storage footprint by a large margin (and enable more
sophisticated compression options), even if we discount the possible
query advantage
15 matches
Mail list logo
