CAFxX

The Case for Automated Granular Data Placement in Distributed Databases

Two Roles, One Key

In every horizontally scalable database—Spanner, CockroachDB, YugabyteDB, TiDB, and their descendants—a primary key quietly serves two masters. It is a logical identifier, the application's stable handle for a specific entity. And it is a physical address, the value that determines which node in the cluster stores the row. These two roles are in fundamental tension.

The tension is visible within a single table. A Documents table keyed by DocumentId—a UUID chosen for global uniqueness—scatters documents uniformly across ranges, because range-partitioned databases assign rows to nodes based on key order. But if most transactions access documents belonging to the same tenant, the physical layout is exactly wrong: rows that are always read together are distributed as far apart as the key space allows. The logical choice (UUID for uniqueness) directly conflicts with the physical need (shared prefix for locali

CAFxX

📂 Minimize allocations in Go

A collection of tips for when you need to minimize the number of allocations in your Go programs.

Use the go profiler to identify which parts of your program are responsible for most allocations.

Caution

Never apply these tricks blindly (i.e. without measuring the actual performance benefit/impact).

[!NOTE]

CAFxX

The distance between deciding and doing is the single most reliable predictor of whether your life will be extraordinary or ordinary. Not talent, not circumstances, not even the quality of your decisions-but how quickly you collapse the space between intention and reality. Think of this gap as a kind of friction coefficient on your existence: the smaller it is, the more of your internal force actually translates into external motion. When you can move from "I should do this" to physically doing it within hours instead of weeks, you're not just accomplishing more-you're operating in a fundamentally different mode of being where your thoughts have immediate consequences in the world, where your inner life and outer life are in constant, tight conversation.

This matters profoundly because success isn't really about outcomes-it's about iteration speed. The person who can decide and act in the same breath gets ten attempts at something while someone with a week-long gap between decision and execution gets one. Th

CAFxX

CAFxX

Bulk memory allocations for Go

Consider the following code:

s := make([]*Foo, N)
for i := range s {
  s[i] = new(Foo)
  // ...
}

CAFxX

package interncache

import (
    "encoding/binary"
	"iter"
	"maps"
    "math"
    "math/bits"
    "math/rand/v2"
	"sync/atomic"

CAFxX

Language/syntax

Shorthand error definition

Instead of things like var ErrFoo = errors.New("foo") or return fmt.Errorf("foo: %d", n) I would like a shorthand syntax that allows to define a new error type.

Simple error

CAFxX

This document lists ISA or processor implementation wishlists/ideas.

They are mostly random ideas; they are not reviewed, guaranteed to work, or even just make sense, but at some point I had good use cases for each one of them.

Third party wishlists

ISA wishlists found elsewhere.

• y-cruncher Technology Wishlist - ISA
• Lockless Inc. X86 Instruction Wishlist

CAFxX

📂 Persistent "pipes" in Linux

In a project I'm working on I ran into the requirement of having some sort of persistent FIFO buffer or pipe in Linux, i.e. something file-like that could accept writes from a process and persist it to disk until a second process reads (and acknowledges) it. The persistence should be both across process restarts as well as OS restarts.

AFAICT unfortunately in the Linux world such a primitive does not exist (named pipes/FIFOs do not persist

CAFxX

package main

import (
	"fmt"
	"math/bits"
	"slices"
	"sort"
	"strings"
	"unicode"
)