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
d. 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
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
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
/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 people
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
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
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 <mibur...@redhat.com> wrote:
Hi,
I was referring to this article by Shipilev (there are few small issues
forgotten in that u
ges 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, 6:10 AM, "Michael Burm
orth 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, "Michael Burman" <mibur...@redhat.com> wrote:
H
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
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
13 matches
Mail list logo
