bluestreak

5 ms·

1.
The Windows DLL loader lock: how a Rust thread can hang your JVM(questdb.com)
7 points by bluestreak 4mo ago|0 comments
2.
A 40-line fix eliminated a 400x performance gap(questdb.com)
370 points by bluestreak 8mo ago|78 comments
3.
A kernel bug froze my machine: Debugging an async-profiler deadlock(questdb.com)
120 points by bluestreak 9mo ago|18 comments
4.
From Rust to reality: The hidden journey of fetch_max(questdb.com)
259 points by bluestreak 1y ago|59 comments
5.
Making a trading Gameboy: A pocket exchange and algo trading platform(questdb.io)
166 points by bluestreak 2y ago|24 comments
6.
Tokio-Rs: Bytes:From_owner(github.com)
1 points by bluestreak 2y ago|0 comments
7.
We opened a public Discourse forum (and you should too)(questdb.io)
2 points by bluestreak 2y ago|0 comments
8.
by bluestreak 3y ago
In certain situations, crossing the JNI boundary can be advantageous. When data resides in "native" memory, outside the Java heap, the coordination of concurrent execution logic can be handled in Java, while the actual execution o
9.
by bluestreak 3y ago
this is THE number one question being asked about QuestDB :) There is a thread that might help https://news.ycombinator.com/item?id=37557880
10.
by bluestreak 3y ago
One of our distribution channels is Maven Central where we ship Java 11 compatible library. Embedded users preclude us from leveraging latest Java features.
11.
by bluestreak 3y ago
Java tooling was excellent back when QuestDB was started and still is excellent today compared to C++.
12.
Fuzz testing: the best thing to happen to our application tests(questdb.io)
103 points by bluestreak 3y ago|24 comments
13.
by bluestreak 3y ago
great, we are on the same page! `fallocate()` (or posix one) is called on large swades of file. 16MB default. Not too often to hurt performance. I wonder if zeroing the file with `fallocate()` will result in actual disk writes or is it ephe
14.
by bluestreak 3y ago
> On x86, and I think every architecture, when you write to a memory mapping that is not already backed by a writable page, the kernel is notified that user code is trying to write. And the kernel needs to fill in the contents of the pag
15.
by bluestreak 3y ago
It is not always read-write-modify. There is no evidence of this pattern in Ubuntu when there is no memory pressure. Merge occurs when block is partially updated after kenel had lost state of the block, which can happen under memory pressur
16.
The Inner Workings of Distributed Databases(questdb.io)
175 points by bluestreak 3y ago|27 comments
17.
by bluestreak 3y ago
I am excited for what Memory API brings. The biggest pain with native memory management for us are "struct" or lack of those. Extremely bug prone memory arithmetic I personally am very motivated to see the back of. FFI - we need t
18.
Show HN: QuestDB with Python, Pandas and SQL in a Jupyter notebook – no install(play.questdb.io)
53 points by bluestreak 4y ago|15 comments
19.
by bluestreak 4y ago
I couldn't agree more. I don't think compiler vectorization is that useful even for columnar (!) database we're building. The specialized JIT doesn't even use AVX512 because too much effort for little to no gain.
20.
by bluestreak 4y ago
Thank you for sharing the post! I’m vlad, cto of questdb - we went all the way trying to optimize CSV ingestion with io_uring, and ended up benchmarking against some OLAP peers in the process, Any feedback is greatly appreciated !
21.
Compatible and Reproducible DBMS Benchmark(github.com)
1 points by bluestreak 4y ago|0 comments
22.
by bluestreak 4y ago
The query Clickhouse picked on does not actually leverage time order. Perhaps clickhouse vendors on this thread can comment on relevance of the date partitioning for this query. My best guess is that it might help the execution logic to cre
23.
by bluestreak 4y ago
"fair" means that we comparing apples to apples. Ad-hoc, unindexed predicate, compiled by QuestDB into AVX2 assembly (using AsmJIT) vs same predicate complied by Clickhouse (I'm assuming by LLVM). One can perhaps view this as
24.
by bluestreak 4y ago
Full disclosure: I am CTO of QuestDB and I took part in JIT implementation. The quote above is not mine, it was written by Clickhouse staff. "utilizes its full indexing strategy" statement is false and is news to me.
25.
by bluestreak 4y ago
I am in fact very proud of my team, who worked very hard on both implementation and the article. It is disappointing to read unfounded insults where we made every effort to be fair.
26.
by bluestreak 4y ago
Our article in question can be found here: https://questdb.io/blog/2022/05/26/query-benchmark-questdb-v... The intent of the article was to showcase JIT-optimised WHERE clause and we did not use any inde
27.
by bluestreak 4y ago
It does result in cease and desist threats quite often. We have been on the receiving end of one.
28.
by bluestreak 4y ago
Aggregation is also optimised quite a bit via SIMD and map-reduce. They are as fast as the “where” predicates. Multiple field keyed aggregation is not as optimal yet. I would also suggest our demo site (free and fully open) to see how queri
29.
by bluestreak 4y ago
Last year we released QuestDB 6.0 and achieved an ingestion rate of 1.4 million rows per second (per server). We compared those results to popular open source databases [1] and explained how we dealt with out of order ingestion under the ho
30.
4Bn rows/sec query benchmark: ClickHouse vs. QuestDB vs. Timescale(questdb.io)
20 points by bluestreak 4y ago|15 comments

More ›