knz42

You should read up on why this think time exists. It has nothing to do with "emulating slow clients" and everything to do with not claiming "I have a fast database" by running gazillion txn/sec on just 1MB of data in RAM.

TPC-C requires that you increase the amount of "live data" if you want to display/advertise more performance. That's the benchmark's rule.

If you want to benchmark something else, that's fine, but then

1) don't call it "TPC-C" 2) don't compare with databases that play by the rules.

The tax code taxes wins, not revenue.

An org that invests all their margin into growth doesn't pay (as much) tax.

The best way though is to create an offshore subsidiary, and then have the subsidiary invoice the main office for "services" or "IP licensing". The invoice becomes a cost and is deducted from revenue. "Everyone" (all the big players) do things like that. It's 100% legal.

> That is literally impossible; a breaking change from X-1 to X+1 must have been introduced in one of the intervals X-1 to X or X to X+1. It the latter, X+1 breaks compatibility, if the former, let X' = X-1 and X'+1 breaks compatibility.

No, that's not how it works. The deprecation is introduced in version X-1; the new behavior is introduced but is opt-in; in version X, the new behavior becomes opt-out; in version X+1 the old behavior is removed.

calver != timestamp version

calver has a number picked up when the release is produced, not when the build is run.

Engineers like calver too! (I do.) Calver tells me very clearly how old a release it and what was the technical landscape when it was released.

For example I know precisely how old ubuntu 16.04 is and what I can expect to (not) be in there.

> I think you mean "makes it impossible to know if a release includes backwards incompatible changes without looking at the release notes, while still having a release number say nothing about other aspects of the significance of a release."

The compatibility guarantees of CockroachDB do not change with this. It's always been the same: version X+1 will remain backward compatible with X but may break compatibility with X-1. Deprecation notices for definitive changes in version X+2 are introduced in version X.

A point not highlighted in OP article is that Enterprise customers are shy to upgrade to a "next major version" because they will _assume_ there are breaking changes in there (even though semver allows bumping the major number without breaking changes).

Calver side-steps this user bias.

> > Since we release on a 6 month cadence, we’re starting to name releases by season and year, which means our next release is now CockroachDB Spring ‘19.

> Ugh. You'd think the creators of a multiregion database would realise half the planet has Autumn the same time as the other half has Spring.

The season name will only be produced in marketing materials mainly targeting North America and Europe. The technical product will be named "19.1". The season name will not appear in an install.

This does not need pclntab.

corrected

I went with the Lenovo Yoga 260.

Motivations:

- all parts replaceable and orderable individually

- real touchpad + 3 physical button

- all the keys on the keyboard

- decent keyboard

- touchscreen + stylus

- multiple USB ports + HDMI + DP outputs

- memory card connector

1) “Native Europeans” are not a thing. The only population there before homo sapiens sapiens invaded Europe was homo sapiens neanderthalensis, and they are now extinct.

2) Europe is indeed, largely made of populations that have migrated through the ages.

It's printed "in bold letters on the label";

and like any sane db deployment you should firewall it off anyway.

Something like this:

1) https://www.sciencedirect.com/science/article/pii/S014193311...

(PDF: https://science.raphael.poss.name/pub/poss.13.micpro.pdf )

"The Apple-CORE project has co-designed a general machine model and concurrency control interface with dedicated hardware support for concurrency management across multiple cores. Its SVP interface combines dataflow synchronisation with imperative programming, towards the efficient use of parallelism in general-purpose workloads. Its implementation in hardware provides logic able to coordinate single-issue, in-order multi-threaded RISC cores into computation clusters on chip, called Microgrids. In contrast with the traditional “accelerator” approach, Microgrids are components in distributed systems on chip that consider both clusters of small cores and optional, larger sequential cores as system services shared between applications.

2) https://ieeexplore.ieee.org/document/7300441/ (PDF: https://science.raphael.poss.name/pub/poss.15.tpds.pdf )

"This article advocates the use of new architectural features commonly found in many-cores to replace the machine model underlying Unix-like operating systems. "

The suggestion to "use SYSTEM instead of END" is suspicious.

SYSTEM spawns the system shell as a sub-process. If one would EXIT from the spawned command.com/cmd.exe, QBASIC would pop up back. I think a user of programs written in this way would find themselves surprised.

> This experience taught me the difference between source code and machine code.

Ironically the way QuickBasic works is that it concatenates the BASIC interpreter with a copy of your .BAS file to form the .EXE file. There is no machine code generated.

Say "CRDB" and move on with your day.

This is factually incorrect. I fly through Schiphol 10+ times a year and never had to take off my shoes. Neither did I in Paris, Berlin, Barcelona, London, Copenhagen, so "it's not a European thing" either.

I did see officers asking specific individuals to take off their shoes, with a specific justification: when either the shoes obviously contain metal, or the individuals go through the X ray machine and it complains and there is no obvious other metallic item.

Note that the underlying data store where a lot of the byte churning happens is RocksDB, written in C++. Also the Go/C++ interface in CockroachDB is coarse to reduce overheads.

(working for cockroach labs)

As explained in the blog (as linked by another response) and the documentation (https://www.cockroachlabs.com/docs/stable/strong-consistency... and https://www.cockroachlabs.com/docs/stable/distributed-transa...) CockroachDB does not use locks, and write intents in the concurrency control scheme are expressed by K/V pair i.e. per table cell.

Meanwhile, I acknowledge that CockroachDB does not yet convey well its performance model so that engineers can get an intuition about it. There is documentation, but it's either too detailed (like the design doc) or too high-level (most of the docs site). This needs a new sort of documentation, which we are working on.

No. ISO C has standardized "float" to 32 bits and "double" to 64 bits. The one that's platform-dependent is "long double".

Can you outline briefly what the benefit of this is compared to mosh?

Hugo.

Hi can you tell us a bit more about this SQL-related project? I'm rather practically interested.

The tests that Aphyr describes are ran regularly, to prevent regressions.

Not yet. On the roadmap though.

Yes. (I work there too)

I wrote the rfc for this "effort": there will be an IR in CockroachDB, just not right now. It's a lot of work and we're not going to do this in one go.