olluk

It's really simple, simplier than I even expected.

It's pretty good, my 16 y.o. son will be stuck in it for many hours. I like that you can select a train and see its stops. It would be equally awesome to select a station and see the train arrivals/departures board.

I agree. It's a sarcasm of the new reality. What is copying vs writing from scratch? The line is blurred now, non-existent. You can ask an LLM to re-write any open source to a degree where there is no definite way to say that it's a derivative.

Close your source if you don't want it to be read by LLM

Hot! Back to the 80s with these memory prices

I'd call managed C#, Java, Go, Pythhon, JS, etc. Something with GC e.g., managed memory

That all true but at some point the combinations of paths explode. It is not possible to write tests for all the combinations then it possible to cover them eventually with some probability. Fuzzing covers more execution path combinations over time.

Perhaps the multi-master approach is the example of system where incoherent does not mean terminal illnesses.

We write to WAL and then register the transaction in the transaction sequence registry. If a concurrent transaction registered between the start and the end of the transaction, we update the current uncommitted transaction data with concurrent transactions and re-try registering it in the sequencer again. To scale to multi-master we will move the transaction sequence registry to a service with a consensus algorithm.

Comparison with old version is actually in the article for the patient reader. It could go to the top but I don't think it will make a difference. At the end of the day it is the article at the official QuestDB website which gives the reader a spoiler about the bias.

I am intrigued what Timescale is going to publish next.

There were 2 queries in the QuestDB benchmark over the same table. ClickHouse didn't even try to match both of them choosing one as a victim. I guess that's what happens when you optimise the data storage for one query.

My personal view is that having fast queries without indexes is quite general outcome.

No, there are no indexes in QuestDB in the article. None. Zero. That's bold mistake in the ClickHouse article. Should be named Yes, QuestDb is Faster.

Looks like QuestDB is faster if you don't optimize your table storage for 1 query.

But if you are okay that only limited number of columns to be scanned faster than others ClickHouse comes first.

What if the purpose of the article is to compare queries without indexes?