@AndresFreundTec

6.5K Followers
79 Following
444 Posts

Long time postgres developer, working at Microsoft.

Account about tech, not politics. For the latter look to @AndresFreundPol

Blueskyhttps://bsky.app/profile/anarazel.de
@pgconfdev Separately from that, I think these are fun graphs (showing the effect of leaving frequency boosting enabled. One shows plain readonly pgbench, the other a costlier aggregation.
@pgconfdev I think the most painful one about doing performance investigations going forward is going to be the iTLB one. There's currently no working control over 2MB pages and coalesced 4k entries being used. Which means binary layout and the current state of memory fragmentation has a lot of performance effects.

A few days ago, at @pgconfdev, I gave a talk about some pitfalls when profiling (and benchmarking) postgres. Turbo boost, iTLB, cpuidle, ...

Slides are here:
https://anarazel.de/talks/2026-05-21-pgconf-profiling-postgres-perils/profiling-postgres-perils.pdf

Scam attempt just now.

Supposedly somebody from google checking in about a change to my account recovery details. Contact via both phone and email, with both a robot and a brit sounding guy.

Knew a bunch of personal details (just stuff one could easily get via leaks etc).

Interesting bit is that it's not clear what they were after. Not a straight attempt at relaying SMS "2FA" or such. Played along until they wanted me to repeat a case number back to them, which seemed too risky.

For our own compute we've been averaging daily:
- 1464 core hours (full cores, not SMT)
- 396 of which were windows (visible due to the licensing cost)
- 40GB of artifacts
- doesn't include macos, which I can't track as easily, due to being self hosted runners

So we will likely need something where we can continue to provide compute ourselves, to keep this affordable.

Any suggestions / experiences where to look next?

Postgres until now has been using cirrus-ci for CI. Unfortunately they're shutting down June 1st.

They had been a good fit for us because:
- some free credits so everyone could run some CI on their own
- supported providing own compute for more demanding cases (via GCP and self hosted mac HW)
- jobs ran in one-off VMs
- support for custom images allowed us to pre-install everything, keeping test times manageable
- VMs not containers was good for perf
- CI job definitions could be run locally

Somehow the number of cases in which one needs to slap __attribute__((always_inline)) on static inline functions to prevent gcc from creating a non-inline [partial] versions in a TU seems to be steadily increasing.
That'd work, but the better fix is to simply not have the lock in the first place :). Which we did a few months ago...

“Floating-Point Printing and Parsing Can Be Simple And Fast”

The fastest known floating-point printer and parsing algorithms - fixed-width printing, shortest-width printing, and parsing, all in 400 lines of Go.

https://research.swtch.com/fp
https://research.swtch.com/fp-proof

research!rsc: Floating-Point Printing and Parsing Can Be Simple And Fast (Floating Point Formatting, Part 3)