Share this page!

Enter URL or ID to Unroll

You can paste full URL like: https://x.com/threadreaderapp/status/1644127596119195649
or just the ID like: 1644127596119195649

How to get URL link on X (Twitter) App

  1. On the Twitter thread, click on or icon on the bottom
  2. Click again on or Share Via icon
  3. Click on Copy Link to Tweet
  4. Paste it above and click "Unroll Thread"!
  5. More info at Twitter Help
Felix Geisendörfer Profile picture
Felix Geisendörfer
@felixge
Senior Staff @datadoghq working on Go Profiling, Performance, OpenTelemetry and more. Before: @Apple, Co-founder @transloadit, @nodejs core dev
Jan 24, 2023 • 4 tweets • 1 min read
Big editor trying to steer windows users away from the true path. EU regulators should look into this 🤣

(If you haven't guessed, I get to debug some Go code on Windows today and we're not off to a good start here) Image Its user interface is unintuitive and its key bindings are awkward?

That's just a libel and defamation case waiting to happen 🙈
Jan 5, 2023 • 12 tweets • 4 min read
How Often Does Go Preempt Goroutines?

The conventional wisdom says CPU-bound goroutines are preempted every 10ms, but this is wrong. #golang Image We can check this with a small test program. Image
Jun 15, 2020 • 10 tweets • 4 min read
Loving this "Looking Back at Postgres" paper. So many excellent burns 🔥 Also plenty of shade for code within PostgreSQL.

(But luckily this code seems to have landed in /dev/null)
Jan 26, 2020 • 22 tweets • 10 min read
1) Are you using #postgres via #docker for mac?

Have you ever noticed `EXPLAIN ANALYZE` slowing down your queries by like 60x?

Let's dig into some #postgres and #linux internals to figure out what's going on! An accessible version of this thread is available at https://github.com/felixge/tweets/tree/master/postgres-docker-explain-analyze 1b) This thread is also available on GitHub: github.com/felixge/tweets…
Jan 20, 2020 • 12 tweets • 3 min read
1) Oh man, computer stuff is hard. A small #postgresql thread:

After spending weeks optimizing an ETL process to be 3x faster, an index-only scan got 3x slower compared to a replica that hadn't undergone the new ETL process. Main clue: (shared) buffer hits were up by 10x. 2) My initial suspicion was vacuum issues or index corruption, but no amount of `VACUUM FULL` or recreating the indexes was helping. So I had to dig deeper.

Enter dynamic tracing with perf: wiki.postgresql.org/wiki/Profiling…