u/funny_falcon

B+Tree has great concurrent algorithms and implementations as well.

But SkipLists are simpler. Way more simpler. And is made of simple clear concepts.

Operations of any kind of binary search tree is not as trivial as for skip list.

Surprisingly, BTree could be simpler, than BST. But Skip Lists are simpler

IMHO, there is a big need of official PUC Rio JIT interpreter for LUA.

 It is surprising to me that your benchmarking potentially leaves a lot of CPU headroom, since it's not representative of production usage

It contradicts my experience: any production tries to not cross 80% CPU usage because behavior becomes unstable otherwise.

60-70% CPU usage is considered as high efficient. Especially on CPU with Hyper Threading.

Give JEdit a try. It is just good code editor. But it really consumes fraction of memory you expect from Java application.

“auto-deploy on push” seems to me as “on prod”

Oh, I see: I misread the code. Both parts (heaping and popping) are bolted into the single loop.

Excuse me for wrong claims.

~heap_sort is not complete! Only “heapify” part is implemented. Popping one-by-one max element from the heap is completely missed.~

~I’ve already seen this mistake in other article. Looks like they copy from same broken implementation.~

I don’t know about Windows. But on Unix most of files will be already on disk at the time fsync will be called on them. That is why fsync will be almost free.

Some backup utilities just postpones flushing till restore end:

• write all files without fsync,
• then walk all files again, open each and fsync
• don’t forget to fsync directories as well afterwards

Making AST interpreter so fast - it's amazing!

It is impressive speedup without switching to bytecode interpreter!

Unfortunately, there are a lot of inconsistencies in the language.

For example:

• if struct's method is inlined, it start to modify the struct itself.
• but if it isn't inlined, then it works on struct's copy.

And there are a lot of corner cases with generics semantic.

PostgreSQL 19 will (likely) have plan hinting builtin/in standard contrib modules.

Long time ago int was 16bit (or close to it). Probably, no one did care.

Aside data storage differences, there is also logging differences:

• PostgreSQL has single Write Ahead redo Log,
• but MySQL has two: “binary log” with sql commands and InnoDB’s redo log. Therefore, MySQL has two logs to make fsync for at each transaction commit.

Other difference is about workarounds against torn (ie, partial) pages writes :

• InnoDB uses “double-write” approach: every page is written to fixed size “double-buffer” first, then into data file. Due to fixed size of double buffer, it had to do it every time page is evicted from buffer.
• PostgreSQL write page's image into WAL log first time the page is modified since checkpoint. Therefore, if page is modified second, third time, it is not written to WAL until next checkpoint.

Both approaches has downsides:

• MySQL may write more data on disk if database doesn’t fit into memory,
• but PostgreSQL has huge increase of WAL traffic after each checkpoint, which harms both query performance and replication performance.

Kotlin, C# and Racket go next. If I had a choice between four "best languages for LLM" for job to be done, I'd rather choose C# or Kotlin.

But if I want to practice pretty language for no money reasons, I may try Elixir.

Afaik, Elixir is not statically typed language, but strongly typed. As well as Python and Ruby, for example.

Problem could be not in amount of garbage relative to whole table size. It could be in amount of garbage relative to hot set of rows.

If you have 100M rows in tables, then 10% garbage is 10M dead row version. But if in this table hot set is 1M rows, then 10M dead row version is 1000%. In other words, your queries to the hot versions could be 10 times slower.

If those 10M versions are spread over all table pages (because of space reuse in partial filled pages), then overhead becomes 100M/1M = 100x.

Yes, these are extremely corner cases, and probably you've never met them. But there are workloads that suffers from it much.

On the one side, you’re right. On the other, if this 10% are thousands versions of several hot tuples, you’re in big trouble. And auto vacuum will not be triggered until next 10% arrive.

Yes, there is so called “micro vacuum” that may clean mark some versions as “dead”, and then some index tuples probably may be deleted eagerly. It were great improvements made last several years. But they are a bit probabilistic, and may be not triggered.

In PostgreSQL update physically implemented as “delete old version” + “insert new version”. There is no difference in space consumption between delete+insert and update in PostgreSQL.

MVCC with undo log (as in Oracle, InnoDB and several others) is also MVCC. But it behaves more predictable, at least if rollback is rare. And rollback is rare usually.

MVCC with row copies (as in Pg) in main pages behaves better in presence of many rollbacks. It allows simpler redo log and doesn't need undo logic at all. But it has worse behavior in many legal scenarios you expect to behave well.

Not only deleting, but updating as well. And updating one row for many times.

Very interesting language

Considering x, Kakoune did it much better. Overall Kakoune has much better movement and editing experience.

But Helix is definitely better integrated with LSP/TreeSitter, and editing many files in one console "window" in splitted tabs is more convenient than opening many console splits/windows for Kakoune.

Helix is just fast. All that it does it does within glimpse. I didn't feel that smoothness from NVim (I've tried AstroNVim two years ago).

I found paused Haruna eats cpu when screen is locked.