Hacker News: olluk

New comment by olluk in "Hey Nico, you didn't vibe code your data room but stole it from Papermark"

olluk — Thu, 25 Jun 2026 13:42:44 +0000

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.

New comment by olluk in "Hey Nico, you didn't vibe code your data room but stole it from Papermark"

olluk — Thu, 25 Jun 2026 13:13:56 +0000

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

New comment by olluk in "Redesigning DuckDB's Sort, Again (2025)"

olluk — Thu, 18 Jun 2026 17:15:27 +0000

Hot! Back to the 80s with these memory prices

New comment by olluk in "Rethinking C++: Architecture, Concepts, and Responsibility"

olluk — Tue, 25 Nov 2025 14:04:35 +0000

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

New comment by olluk in "Fuzz testing: the best thing to happen to our application tests"

olluk — Thu, 17 Aug 2023 23:07:49 +0000

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.

New comment by olluk in "The Inner Workings of Distributed Databases"

olluk — Mon, 17 Apr 2023 21:53:19 +0000

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

New comment by olluk in "The Inner Workings of Distributed Databases"

olluk — Mon, 17 Apr 2023 21:45:21 +0000

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.

New comment by olluk in "No, QuestDB is not Faster than ClickHouse"

olluk — Thu, 16 Jun 2022 22:43:55 +0000

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.

New comment by olluk in "No, QuestDB is not Faster than ClickHouse"

olluk — Thu, 16 Jun 2022 20:49:19 +0000

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.

New comment by olluk in "No, QuestDB is not Faster than ClickHouse"

olluk — Thu, 16 Jun 2022 20:43:25 +0000

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

New comment by olluk in "No, QuestDB is not Faster than ClickHouse"

olluk — Thu, 16 Jun 2022 19:59:45 +0000

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.

New comment by olluk in "No, QuestDB is not Faster than ClickHouse"

olluk — Thu, 16 Jun 2022 19:51:41 +0000

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.

New comment by olluk in "No, QuestDB is not Faster than ClickHouse"

olluk — Thu, 16 Jun 2022 19:48:00 +0000

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