I've been investigating this, but a bit slowly as was looking in the wrong
place. I haven't yet confirmed, but I have a strong suspicion of the
problem. Could you confirm the total physical memory on the nodes? If 8gb
or less, try applying the not yet committed patches in CASSANDRA-6692
(atomic b
It's only been six months since the last performance drive, and 2.1 is now
around the corner. But I'm hoping we can push performance even further for
3.0. With that in mind, I've picked out what I think are the nearest term
wins to focus on.
- CASSANDRA-7039: DirectByteBuffer compatible LZ4
%20project%20%3D%20CASSANDRA%20AND%20status!%3Dresolved
Benedict, you might want to un-assign from yourself anything you're
not working on in the near future in case anyone else wants to grab
one.
On Tue, Apr 15, 2014 at 3:28 PM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
It's only
, Benedict Elliott Smith wrote:
It's only been six months since the last performance drive, and 2.1 is now
around the corner. But I'm hoping we can push performance even further for
3.0. With that in mind, I've picked out what I think are the nearest term
wins to focus on.
- CASSANDRA-7039
+1 unit tests
On 21 May 2014 02:36, Jake Luciani jak...@gmail.com wrote:
I think having cql unit tests is certainly a good idea. It doesn't replace
dtests but makes it easier to have better coverage locally.
On Tue, May 20, 2014 at 7:10 PM, Tyler Hobbs ty...@datastax.com wrote:
Sylvain
Graham,
This is largely fixed in 2.1 with the introduction of partially off-heap
memtables - the slabs reside off-heap, so do not cause any GC issues.
As it happens the changes would also permit us to recycle on-heap slabs
reasonable easily as well, so feel free to file a ticket for that,
We need to add 7245 to that list. I'll try to get to it tomorrow.
On 21 May 2014 17:40, Tyler Hobbs (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/CASSANDRA-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
Tyler Hobbs reassigned
I would for defining the cql tests in a way that permits them being run as
both dtests and unit tests. But since we're on python for dtests that could
be troublesome.
On 22 May 2014 17:03, Jeremiah D Jordan jerem...@datastax.com wrote:
The only thing I worry about here is that the unit tests
)
Thanks,
Graham.
On May 21, 2014, at 2:20 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
Graham,
This is largely fixed in 2.1 with the introduction of partially off-heap
memtables - the slabs reside off-heap, so do not cause any GC issues.
As it happens the changes
cassandra with different usage patterns, and it is hard to mimic
production load on all of them at the same time in beta
Thanks anyway for your detailed explanations,
Graham
On Jun 15, 2014, at 1:11 PM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
Hi Graham,
Unfortunately
to install it yourself) one.
Thanks,
Graham.
On Jun 15, 2014, at 2:04 PM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
The current implementation is slower for a single memtable-only read
(dependent on workload, but similar ball park to on heap), but can store
substantially
Pretty sure we got this head of the hydra. Question is if any more will
spring up in its place.
On Wed, Jul 2, 2014 at 7:28 PM, Jonathan Ellis jbel...@gmail.com wrote:
https://issues.apache.org/jira/browse/CASSANDRA-7465 is a pretty big
one, I'd like to get some more testing with the fix
AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
Pretty sure we got this head of the hydra. Question is if any more will
spring up in its place.
On Wed, Jul 2, 2014 at 7:28 PM, Jonathan Ellis jbel...@gmail.com
wrote:
https://issues.apache.org/jira/browse/CASSANDRA
This discussion is probably better had on JIRA, but I favour an
asynchronous approach permitting only one modifying thread access to the
structure at a time, with each competing modification simply chaining their
to-be-merged state to a pending-list, which is repaired at read time if it
isn't
I'd prefer to patch CASSANDRA-7743 first.
On Wed, Aug 13, 2014 at 10:47 PM, Brandon Williams dri...@gmail.com wrote:
+1
On Aug 13, 2014 7:33 AM, Sylvain Lebresne sylv...@datastax.com wrote:
I propose the following artifacts for release as 2.1.0-rc6. As it is
just
a
RC, we'll keep the
Done
On Fri, Sep 5, 2014 at 4:34 PM, Jay Patel pateljay3...@gmail.com wrote:
Hi Folks,
Seems like I'm not able to assign this tix to myself. Can anyone help to
assign to me? These all are actually related but I opened as separate just
to track.
CASSANDRA-7882
Hi Mark,
This specific heuristic is unlikely to be applied, as (if I've understood
it correctly) it has a very narrow window of utility to only those updates
that hit *exactly* the same clustering columns (cql rows) *and *data
columns, and is not trivial to maintain (either cpu- or memory-wise).
Fair enough (and yes, it did)
On Mon, Sep 8, 2014 at 2:40 PM, Sylvain Lebresne sylv...@datastax.com
wrote:
On Sep 7, 2014 4:41 PM, Benedict Elliott Smith
belliottsm...@datastax.com
wrote:
I've just commited 7519, which would be nice (but not essential) to
include
in 2.1.0, since
It's quite possible support could be added to evaluate a UDF as part of the
condition check. The code you're looking for are implementors of
CASRequest.appliesTo(), in CQL3CasRequest and
CassandraServer.ThriftCASRequest
It seems like https://issues.apache.org/jira/browse/CASSANDRA-8488 would
I think the problem is everyone currently contributing is comfortable with
ant, and as much as it is imperfect, it isn't clear maven is going to be
better. Having the requisite maven functionality linked under the hood
doesn't seem particularly preferable to the inverse. The status quo has the
need to contribute much quicker.
Here we have the same problem, we have a complex non modular build system,
and core cassandra dev are used to it, so it's not needed to make something
more flexible, even if it could facilite external contribution.
2015-03-31 23:42 GMT+02:00 Benedict Elliott
with discipline and then measure it.
IMO The only artifact worth to extract out of C* tree, and useful for a
(limited) set of 3rd party code, is something like
”cassandra-jmx-interfaces.jar”
Robert
Am 02.04.2015 um 11:30 schrieb Benedict Elliott Smith
belliottsm...@datastax.com
If you're connecting via thrift, all your traffic is most likely being
routed to just one node, which then communicates with the other nodes for
you.
On Wed, Apr 22, 2015 at 6:11 AM, Anishek Agarwal anis...@gmail.com wrote:
Forwarding it here, someone with Cassandra internals knowledge can help
* is ahead of our SOLR indexes
The static columns and the regular columns ARE completely different in
behavior/lifecycle, so I’d definitely vote for them being treated as
such.
On May 1, 2015, at 7:27 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote
) it seems much easier to flush a
single memtable to more than one stable on disk (static and non static) and
then allow for separate compaction of those
On May 1, 2015, at 9:06 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
It also doesn't solve the atomicity problem, which
How would it be different from creating an actual real extra table instead?
There's nothing that warrants making the codebase more complex to
accomplish something it already does.
As far as I was aware, the only point of static columns was to support the
thrift ability to mutate and read
A good practice as a committer applying a patch is to build and run the
unit tests before updating the main repository, but to do this for every
branch is infeasible and impacts local productivity. Alternatively,
uploading the result to your development tree and waiting a few hours for
CI to
follow on commit wouldn't
you need to force push?
On Thu, May 7, 2015 at 9:28 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
If we do it, we'll end up in weird situations which will be annoying for
everyone
Such as? I'm not disputing, but if we're to assess the relative
trunk without coming across broken revisions.
Then balance the value of that with the cost of the process.
Ariel
On Thu, May 7, 2015 at 10:41 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
It's a bit unfair to characterize Aleksey as subscribing to a cargo
cult
at 10:36 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
wouldn't you need to force push?
git push --force-with-lease
This works essentially like CAS; if the remote repositories are not
the
same as the one you have modified, it will fail. You then fetch
merge.
At this size I don't see the need for a staging branch to prevent trunk
from ever breaking. There is a size where it would be helpful I just
don't
think we are there yet.
Ariel
On Thu, May 7, 2015 at 5:05 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote
for trying to avoid extra work/stability but we already have
added a layer of testing every change before commit. I'm not going to
accept we need to also add a layer of testing before every merge.
On Thu, May 7, 2015 at 10:36 AM, Benedict Elliott Smith
belliottsm...@datastax.com wrote
I have no position on this, but I would like to issue a word of caution to
everyone excited to use the new JDK8 features in development to please
discuss their use widely beforehand, and to consider them carefully. Many
of them are not generally useful to us (e.g. LongAdder), and may have
02.04.2015 um 11:30 schrieb Benedict Elliott Smith
belliottsm...@datastax.com:
There are three distinct problems you raise: code structure,
documentation,
and build system.
The build system, as far as I can tell, is a matter of personal
preference.
I personally dislike the few interactions
.
Ariel
On Fri, Apr 10, 2015 at 7:07 PM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
CASSANDRA-8459 https://issues.apache.org/jira/browse/CASSANDRA-8459
autocompaction
on reads can prevent memtable space reclaimation
Can you link a ticket to CASSANDRA-9012
on the ticket so that these scenarios are amongst those
explicitly considered when we address it, but I expect the scope of that
ticket to be very broad, and probably introduce its own entire class of
subtickets.
Thanks,
Ariel
On Fri, Apr 10, 2015 at 8:04 AM, Benedict Elliott Smith
belliottsm
I've started leaning towards a hybrid approach:
I put everything I want to say, including some code changes, and sometimes
complex argumentation into comments the branch. I differentiate these into
two categories:
1. Literal comments, to remain for posterity - typically things I agree
(git history navigation is also much more powerful in the IDE, in my
experience - can quickly scoot through many prior versions to see what the
context of prior authors was)
On Wed, Jul 8, 2015 at 9:15 PM, Benedict Elliott Smith
belliottsm...@datastax.com wrote:
Except that it would lack code
Except that it would lack code navigation. So it would be alt-tabbing, then
clicking through the clunky interface to find the file I want, and the
location, which can be very cumbersome.
On Wed, Jul 8, 2015 at 9:13 PM, Josh McKenzie josh.mcken...@datastax.com
wrote:
If you navigate in an
While that approach optimises for people paying close attention to the JIRA
firehose, it is less optimal for people trying to figure out after the fact
what is going on wrt certain tickets. Some of the more complex tickets I
cannot make head or tails of even when I was one of the main
For newcomers that (
https://github.com/apache/cassandra/blob/cassandra-3.0.0/guide_8099.md) is
probably a bad document to point them to, as it will no doubt confuse them
- the naming, behaviour and format descriptions are all now partially
incorrect.
It was, by its own admission, intended only
Compact storage should really have been named "not wasteful storage" - now
everything is "not wasteful storage" so it's void of meaning. This is true
without constraint. You do not need to limit yourself to a single non-PK
column; you can have many and it will remain as or more efficient than
Jack Krupansky
>
> On Mon, Apr 11, 2016 at 5:03 PM, Jeremiah Jordan <jerem...@datastax.com>
> wrote:
>
> > As I understand it "COMPACT STORAGE" only has meaning in the CQL parser
> > for backwards compatibility as of 3.0. The on disk storage is not
> affect
I think -1 lacks a little clarity when responding to a block of prose with
multiple clauses, suggestions and no single proposition requiring a yes/no
answer.
As fun as it is to type -1.
On Thursday, 28 July 2016, Jake Luciani >
their life
and sanity.
On 16 August 2016 at 20:49, Eric Evans <john.eric.ev...@gmail.com> wrote:
> On Tue, Aug 16, 2016 at 2:38 PM, Benedict Elliott Smith
> <bened...@apache.org> wrote:
> > I think all complex, nuanced and especially emotive topics are
> challenging
> &
> [not associated with Datastax]
>
>
>
> On 2016-08-16 13:47, Benedict Elliott Smith wrote:
>
>> This is a much more useful focusing of the discussion, in my opinion. It
>> seemed to me that city hall was focusing on a very narrow definition of
>> pr
for
misinterpretation, as well as correcting the inevitable misinterpretations
that happen anyway. But that's a major side track we shouldn't deviate
down.
On 16 August 2016 at 20:28, Eric Evans <john.eric.ev...@gmail.com> wrote:
> On Tue, Aug 16, 2016 at 1:34 PM, Benedict Elliott Smith
This is a much more useful focusing of the discussion, in my opinion. It
seemed to me that city hall was focusing on a very narrow definition of
project health.
I would be the first to say the project need to improve here, but doing so
will be challenging; I'm not sure anyone really knows how
Unfortunately when rulebooks are consulted to shape this kind of
discussion, their ambiguity begins to show. What does it mean for
something "to happen" on a mailing list? It must be a loose
interpretation, because clearly many things do not "happen" on the mailing
list, such as all of the code
By this definition the Cassandra project is already compliant? There's a
commits@ mailing list that behaves just as you describe.
I'd personally like to see some reform with how these things work, but
mostly because commits@ is rarely going to be subscribed to by anybody who
isn't working full
It's worth noting more clearly that 3.5 is an arbitrary point in time. All
3.X releases < 3.6 are affected.
If we backport to 3.5, it seems like 3.1 and 3.3 should get the same
treatment. I do recall commitments to backport critical fixes, but exactly
what the bar is was never well defined.
I
Yes, agreed. I'm advocating a different cadence, not a random cadence.
On Thursday, 15 September 2016, Tyler Hobbs <ty...@datastax.com> wrote:
> On Thu, Sep 15, 2016 at 2:22 PM, Benedict Elliott Smith <
> bened...@apache.org <javascript:;>
> > wrote:
>
&
I agree tick-tock is a failure. But for two reasons IMO:
1) Ultimately, the users are the real testers and it takes a while for a
release to percolate into the wild for feedback. The reality is that a
release doesn't have its tires properly kicked for at least three months
after it's cut. So
me replying
> to your messages anymore, at least on list.
>
> > On Nov 6, 2016, at 11:19 AM, Benedict Elliott Smith <bened...@apache.org>
> wrote:
> >
> > In summary: you claim to be someone with years of experience at the
> forefront of an organisation that cond
Jim,
I would love it if you could take the time to explain how arrived at a
diagnosis of trolling.
Aleksey made a well written, cogent and on-topic criticism of your ongoing
behaviour, as well as a reasoned rebuttal of your absurd claim that your
power is inherent to *you*, not your position (I
above warrants what you consider well-written, cogent,
> on-topic and reasoned, then I fear that any further discussion
> is really worthless.
>
> o+o
>
> > On Nov 6, 2016, at 11:24 AM, Benedict Elliott Smith <bened...@apache.org>
> wrote:
> >
> > Jim,
>
In summary: you claim to be someone with years of experience at the
forefront of an organisation that conducts all of its business primarily
over email. In that time you have not learned to express yourself over
email in a manner that is not incendiary to those reading it, nor offensive
to the
Thanks Jeff, that was very well put.
I would quibble on one point, though: the ship has never sailed on topics
of community. How the board acts towards the PMC and companies in the
community matters a great deal for continuing relations, as well as for
other projects.
The question is: did the
id a lot for Cassandra, but the public perception nowadays
> seems to be that DataStax donated Cassandra to the ASF. This is not true.
> It was created and contributed by Facebook
> https://wiki.apache.org/incubator/Cassandramany years before DataStax was
> even founded
>
>
&g
LONG time. Just not in public. So this is nothing which just
> boiled up the last month - this really got pointed out amicably by the
> board for a LONG time before _finally_ they took actions!
>
>
> LieGrue,
> strub
>
>
> On Saturday, 5 November 2016, 14:42, Benedict Ellio
ow what’s been happening inside your
> project, we don’t pass judgement. To make us care you must have your
> community speak with one voice. Demonstrate that you have consensus around
> your opinions. Then, and only then, will the membership - the people who
> vote for the board and ho
Hi Ed,
I would like to try and clear up what I perceive to be some
misunderstandings.
Aleksey is relating that for *complex* tickets there are desperately few
people with the expertise necessary to review them. In some cases it can
amount to several weeks' work, possibly requiring multiple
This discussion is bundling up two issues:
1) Did DataStax have an outsized role on the project which needed to be
offset, preferably with increased participation?
2) Did the Board behave reasonably in trying to fix it?
As far as I can tell the answers are 1) Yes, 2) No
Can the board please
PMC
> should understand how the project should be run, its not the boards job to
> fix it directly. Did the board act unreasonably? I don't think so. Did some
> heated discussions take place? Undoubtedly.
>
>
>
> On Sat, Nov 5, 2016 at 12:28 AM, Benedict Elliott Smith <
> b
Hi Mark,
Thanks, that was a calm and diplomatic email.
recognise where they might need to apologise
I will start the ball rolling here, as I have not always been generous in
my interpretations of others' actions, and have certainly contributed to
escalation.
But I wonder if you would also
... and continuing in the fashion of behaviours one might like to disabuse
people of, no code link is provided.
On 18 October 2016 at 16:28, Michael Kjellman
wrote:
> We use posix_fadvise in a bunch of places, and in stereotypical Cassandra
> fashion no comments
This is what JIRA is for. It seems to date back to CASSANDRA-1470, where
the default became immediately evicting newly compacted files.
This results in cold reads for *hot* data after compaction, so
CASSANDRA-6916 permitted evicting the *old* data instead, while
guaranteeing >= the same amount
commits and read thru a billion tickets to maybe understand why
> something was done. Clearly thru the conversations on this topic I've had
> on IRC and the responses so far on this email thread it's not/still not
> obvious.
>
> best,
> kjellman
>
> On Oct 18, 20
Wow, that was quite the aggressive email. The thing is, it very much looks
like the only reason you care about this delay is because Kellabyte is
making the ASF board look bad on twitter. If it weren't the case, it seems
unlikely such a "slow" 12hr response would receive board notice, let alone
Mattmann <mattm...@apache.org> wrote:
>
>
> On 2016-11-04 09:51 (-0700), Benedict Elliott Smith <bened...@apache.org>
> wrote:
> > Wow, that was quite the aggressive email. The thing is, it very much
> looks
> > like the only reason you care about this delay is
This link is a helpful segway to another problem with MVs and defaults - the
default behavioural unsafety we opt for by not writing through the batch log,
opening far more windows for data inconsistency than the algorithm otherwise
permits. Without a way to detect or repair these
the specifics of
> any other features. So yes, I would prefer my bank to use MV’s as they are
> today over rolling their own, and getting it even more wrong.
>
> Now, even given all that, if we want to warn users of the pit falls of using
> MV’s, then lets do that. But l
While many users may apparently be using MVs successfully, the problem is how
few (if any) know what guarantees they are getting. Since we aren’t even
absolutely certain ourselves, it cannot be many. Most of the shortcomings we
are aware of are complicated, concern failure scenarios and
I'm strongly in favour of it; it's always bugged me, and I hadn't realised
it might be contentious to implement.
I'd be in favour of never retiring the _ms format though - it's almost
free, there's no backward compatibility problems, and it's fairly intuitive
so long as we're consistent about it.
We already store the minimum timestamp in the EncodingStats of each
partition, to support more efficient encoding of atom timestamps. This
just isn't exposed beyond UnfilteredRowIterator, though it probably could
be.
Storing the max alongside would still require justification, though its
cost
(Obviously, not to detract from the points that Jon and Jeremiah make, i.e.
that if TTLs or tombstones are involved the metadata we have, or can add,
is going to be worthless in most cases anyway)
On 14 January 2018 at 16:11, Benedict Elliott Smith <bened...@apache.org>
wrote:
> We alre
t for me?
>
> On 2018-01-14 17:16, Benedict Elliott Smith <bened...@apache.org> wrote:
> > (Obviously, not to detract from the points that Jon and Jeremiah make,
> i.e.
> > that if TTLs or tombstones are involved the metadata we have, or can add,
> > is going to be w
For the record, I'm not certain there *is* a great deal of value in this.
The read latency metrics are expected to vary a great deal, since the
entire IO subsystem is involved.
Writes, however, go straight to a memtable. They only block on IO if we
exceed our commit log flush bandwidth for an
If you look closely, there can be multiple memtables extant at once. While
all "new" writes are routed to the latest memtable, there may still be
writes that have begun but not yet completed. The memtable cannot be
flushed until any stragglers have completed, and some stragglers *may* still
need
Sorry, I guess I'm tired. I thought this was discussing local write
latency.
I'm surprised we have that and not coordinator write latency.
Please do ignore me, I'm not sure why I got involved!
On 13 February 2018 at 21:48, Benedict Elliott Smith <bened...@apache.org>
wrote:
> For t
; including SSTable read and timestamp comparison etc.)
>
> -Original Message-
> From: Benedict Elliott Smith [mailto:bened...@apache.org]
> Sent: Tuesday, February 13, 2018 2:25 PM
> To: dev@cassandra.apache.org
> Subject: Re: Use of OpOrder in memtable
>
> If y
I agree this is a mess. I think we have previously taken the view that JIRA
should be the permanent record of discussion, and that as such the git
conversation should be duplicated there.
However, I think it would be better for JIRA to get a summary of important
discussions, by one of the
Also +1
It might perhaps be nice to (just once) have ASF Bot comment that a GitHub
discussion has been replicated to the worklog? In the Arrow example, for
instance, it isn’t immediately obvious that there are any worklog comments to
look at.
Or perhaps we should require committers to
+1 also for separate repo
> On 24 Aug 2018, at 01:11, Jeff Jirsa wrote:
>
> +1 for separate repo
>
>
> --
> Jeff Jirsa
>
>
>> On Aug 23, 2018, at 1:00 PM, sankalp kohli wrote:
>>
>> Separate repo is in a majority so far. Please reply to this thread with
>> your responses.
>>
>> On Tue,
+1.
> On 9 Jul 2018, at 20:17, Mick Semb Wever wrote:
>
>
>> We have done all this for previous releases and we know it has not worked
>> well. So how giving it one more try is going to help here. Can someone
>> outline what will change for 4.0 which will make it more successful?
>
>
> I
it's
> probably just noise now, so I won't respond any further on this
> thread. I don't anticipate having a personal need to commit to a
> future 5.0 release before 4.0 is out, so it won't impact me
> personally.
>
> On Tue, Jul 10, 2018 at 10:32 AM Benedict Elliott Smith
> w
ound(1) returns double 3
>>
>> So as we're going to have silly values in any case, why pretend something
>> else? Also, exact calculations are slow if we crunch large amount of
>> numbers. I guess I slightly deviated towards Postgres' implemention in this
>> case, but
double. This would be something the spec allows.
>
> Definitely if we can make overflow not occur we should and the spec allows
> that. We should also not return different types for the same operand types
> just to work around overflow if we detect we need more precision.
&
a lot. It's a bit
>>> suspicious really when you look at the ratio of performance to block size
>>> being close to 1:1. I couldn't spot a bug in the benchmark though.
>>>
>>> Compression ratios with LZ4 fast for the text of Alice in Wonderland was:
>>>
>&
Shall we move this discussion to a separate thread? I agree it needs to be
had, but this will definitely derail this discussion.
To respond only to the relevant portion for this thread:
> changing years-old defaults
I don’t see how age is relevant? This isn’t some ‘battle hardened’ feature
FWIW, I’m not -0, just think that long after the freeze date a change like this
needs a strong mandate from the community. I think the change is a good one.
> On 17 Oct 2018, at 22:09, Ariel Weisberg wrote:
>
> Hi,
>
> It's really not appreciably slower compared to the decompression we
As far as I can tell we reached a relatively strong consensus that we should
implement lossless casts by default? Does anyone have anything more to add?
Looking at the emails, everyone who participated and expressed a preference was
in favour of the “Postgres approach” of upcasting to decimal
is old, I've learned that it pays to
> be very, very cautious.
>
> On Tue, Oct 23, 2018 at 3:33 PM Jeff Jirsa wrote:
>
>> My objection (-0.5) is based on freeze not in code complexity
>>
>>
>>
>> --
>> Jeff Jirsa
>>
>>
>>> O
I’m +1 change of default. I think Jeff was -1 on that though.
> On 23 Oct 2018, at 16:46, Ariel Weisberg wrote:
>
> Hi,
>
> To summarize who we have heard from so far
>
> WRT to changing just the default:
>
> +1:
> Jon Haddadd
> Ben Bromhead
> Alain Rodriguez
> Sankalp Kohli (not explicit)
.5 respectively.
>
> Ariel
>
> On Tue, Oct 23, 2018, at 11:50 AM, Benedict Elliott Smith wrote:
>> I’m +1 change of default. I think Jeff was -1 on that though.
>>
>>
>>> On 23 Oct 2018, at 16:46, Ariel Weisberg wrote:
>>>
>>> Hi,
>
Just want to say +1, and thanks for taking the time to do this. This all
sounds great.
(And completely supersedes what I hoped to achieve with CASSANDRA-14648)
> On 26 Oct 2018, at 15:49, Stefan Podkowinski wrote:
>
> I'd like to give you a quick update on the work that has been done
>
low if we detect we need more precision.
>
> Ariel
> On Fri, Oct 12, 2018, at 12:45 PM, Benedict Elliott Smith wrote:
>> If it’s in the SQL spec, I’m fairly convinced. Thanks for digging this
>> out (and Mike for getting some empirical examples).
>>
>> We still have to
p#L2213
> <https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L2213>
> https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L3764
> <https://github.com/VoltDB/voltdb/blob/master/src/ee/common/NValue.hpp#L3764>
>
> Ariel
>
>
f results sets actually sounds worse if we want
> to also improve aggregrations. Many applications won't notice if the client
> library abstracts that away, but I think there are still cases where people
> would notice the type changing.
>
> Ariel
>
>> On Tue, Oct 2, 2018,
CASSANDRA-11935 introduced arithmetic operators, and alongside these came
implicit casts for their operands. There is a semantic decision to be made,
and I think the project would do well to explicitly raise this kind of question
for wider input before release, since the project is bound by
1 - 100 of 370 matches
Mail list logo