DEV Community: Sysemperor

How to Correctly Read a PostgreSQL EXPLAIN ANALYZE Output

Sysemperor — Thu, 28 May 2026 09:30:40 +0000

A slow query lands in your lap. You run EXPLAIN ANALYZE and get back a wall of indented text that looks like someone fed a query plan through a blender. Most developers stare at it for a few minutes and give up.

You do not need to understand every node. There are five patterns that cover the vast majority of real-world slow queries, and once you can spot them, the output goes from intimidating to immediately actionable.

Run it

EXPLAIN ANALYZE
SELECT u.name, COUNT(o.id) AS order_count
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
GROUP BY u.id, u.name
ORDER BY order_count DESC
LIMIT 10;

Add BUFFERS to also see cache hit rates:

EXPLAIN (ANALYZE, BUFFERS)
SELECT ...

Read the output

The result is a tree of nodes, indented to show parent-child relationships. Each node performs one step of the query. The overall query is the root node; the deepest indented nodes run first.

Limit  (cost=1243.56..1243.58 rows=10 width=40) (actual time=48.231..48.234 rows=10 loops=1)
  ->  Sort  (cost=1243.56..1268.56 rows=10000 width=40) (actual time=48.228..48.229 rows=10 loops=1)
        Sort Key: (count(o.id)) DESC
        Sort Method: top-N heapsort  Memory: 25kB
        ->  HashAggregate  (cost=868.00..968.00 rows=10000 width=40) (actual time=42.118..44.891 rows=10000 loops=1)
              Group Key: u.id, u.name
              ->  Hash Left Join  (cost=295.00..743.00 rows=50000 width=16) (actual time=4.532..28.714 rows=50000 loops=1)
                    Hash Cond: (o.user_id = u.id)
                    ->  Seq Scan on orders  (cost=0.00..789.00 rows=50000 width=8) (actual time=0.012..7.341 rows=50000 loops=1)
                    ->  Hash  (cost=170.00..170.00 rows=10000 width=12) (actual time=4.102..4.102 rows=10000 loops=1)
                          ->  Seq Scan on users  (cost=0.00..170.00 rows=10000 width=12) (actual time=0.010..2.218 rows=10000 loops=1)
Planning Time: 1.234 ms
Execution Time: 48.512 ms

Each node shows two cost/row estimates:

cost=start..total — the planner's estimate. start is the cost before the first row can be returned; total is the cost to return all rows. Units are arbitrary but consistent.
actual time=start..total — the real measured time in milliseconds.
rows — how many rows were actually returned.
loops — how many times this node ran. Actual time is per loop, so multiply by loops for the total.

Find the slow node

The actual time value on a node includes all child nodes. The node doing the most work is the one with the highest actual time that is not caused by slow children. Compare actual time at each level to find where time is actually consumed.

Look for a big jump: if the parent took 48ms and its child took 44ms, the parent itself only contributed 4ms. If the parent took 48ms and all children took 5ms total, the parent's own work is 43ms — investigate that node.

The patterns to recognise

Sequential scan on a large table (Seq Scan):

Seq Scan on orders (cost=0.00..789.00 rows=50000 ...)

A sequential scan reads every row. Fine for small tables or when you need most of the rows. A problem when you are selecting a small fraction of a large table. The fix is usually an index.

Row estimate wildly off:

(cost=... rows=10000 ...) (actual ... rows=950000 ...)

The planner estimated 10,000 rows but got 950,000. Bad estimates lead to bad plan choices. Run ANALYZE tablename to update statistics and see if the estimate improves. Outdated statistics are the most common cause of bad query plans.

Nested Loop on large tables:

Nested Loop (... rows=50000 loops=1000)
  ...

A nested loop runs the inner query once for each row in the outer query. Fine when the outer table is small or the inner side is indexed. A nested loop with loops=1000 and a sequential scan inside is almost always the reason a query is slow.

Hash Join:

A hash join is usually efficient — PostgreSQL builds an in-memory hash table from the smaller side, then probes it. If memory is too small, the hash spills to disk (Batches: 8 instead of Batches: 1 in the output). Increase work_mem for the session if hash batches are high:

SET work_mem = '64MB';
EXPLAIN (ANALYZE, BUFFERS) SELECT ...;

Check index usage

When a query is slow on a large table and you expect an index to be used:

EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 42;

If you see Seq Scan instead of Index Scan, either:

The index does not exist
The column is not indexed
The query is returning a large enough fraction of rows that PostgreSQL prefers a sequential scan (this is correct behaviour)
Statistics are outdated and PostgreSQL underestimates selectivity

Check existing indexes:

\d orders

Or:

SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'orders';

Create an index and verify

CREATE INDEX CONCURRENTLY idx_orders_user_id ON orders (user_id);

CONCURRENTLY builds the index without locking the table for writes. Run EXPLAIN ANALYZE again after the index exists — the plan should show Index Scan or Bitmap Index Scan instead of Seq Scan.

SysEmperor's freshly released EXPLAIN Query Analyzer will analyze your EXPLAIN outputs in a clean environment, directly in your browser.

When the planner is still choosing a bad plan

If you have added an index and the planner is still doing a sequential scan on a selective query:

ANALYZE orders;    -- update table statistics

If that does not help, check whether the column has a very skewed distribution (many NULLs, one dominant value). For those cases, partial indexes and extended statistics give the planner more accurate information to work with.

Found this useful? SysEmperor has more database and Linux tutorials, free developer tools, and downloadable AI skills at sysemperor.com.

git bisect: Find the Commit That Broke Everything

Sysemperor — Tue, 26 May 2026 08:56:10 +0000

There is a particular kind of dread that comes with opening a bug report, running git log, and seeing 300 commits between "this worked" and "this doesn't." Most people start at HEAD and work backwards one commit at a time. There is a much better way.

git bisect does a binary search through your commit history. You tell it one commit where things were good and one where they are bad. It checks out the midpoint. You test and say good or bad. It halves the search space and repeats. It finds the culprit in at most eight steps regardless of whether you have 50 commits or 5,000.

How it works

You mark a known-good commit and a known-bad commit. Git checks out the midpoint. You test and tell Git whether that commit is good or bad. Git halves the search space and repeats. After a handful of rounds, it pinpoints the first bad commit.

Start a bisect session

git bisect start
git bisect bad                     # current commit is bad
git bisect good v1.4.0             # this tag (or hash) was working

Git checks out a commit halfway between the two. Test the code — does the bug exist?

git bisect good    # bug is NOT present in this commit
git bisect bad     # bug IS present in this commit

Repeat until Git announces the culprit:

b2c3d4e5 is the first bad commit
commit b2c3d4e5
Author: ...
Date:   ...

    feat: add pagination to user list

End the session

git bisect reset

This returns you to the branch you started from. Always run this when you are done — leaving a bisect session open causes confusing behaviour with other Git commands.

Automate with a test script

If you have a script that exits 0 when the code is good and non-zero when it is bad, you can automate the entire process:

git bisect start
git bisect bad HEAD
git bisect good v1.4.0
git bisect run ./scripts/test-feature.sh

Git runs the script at each step and marks the result automatically. The session finishes without any input from you, often in under a minute.

The script needs to be reliable — flaky tests will mislead the binary search. It also needs to be compatible with the range of commits being tested, which is sometimes a problem if the test itself depends on a file that did not exist in older commits.

Find when a file changed significantly

If you know which file is involved but not which commit touched it:

git log --oneline path/to/file.js

This narrows the suspect list. If the list is short enough, reviewing the diffs directly is faster than a bisect. For a long list, start bisect with the earliest commit that touches that file as the known-good point.

When bisect is hard to use

The bug is not reproducible with a simple script. Manual bisect still works — you just test by hand at each step. Even manually, binary search on 100 commits takes at most 7 rounds.

The build is broken on many commits. Tell Git to skip commits where you cannot test:

git bisect skip

Git moves to a nearby commit and continues. The final result will be a range of commits rather than a single one if the true culprit is adjacent to a skipped commit.

The bug is a performance regression. Benchmark scripts work fine as the test command — exit 0 if performance is acceptable, exit 1 if not. The threshold needs to be reliable enough that the result does not flip due to system noise.

The result is a starting point, not the full answer

git bisect finds the commit that first exhibited the bug — but the commit that caused it might be earlier. The commit git identifies might be an innocent victim: it calls a function that was broken by an earlier change, or it exercises a code path that already had a latent bug.

Once you have the commit, read the diff:

git show b2c3d4e5

Understand what it changed. Then look at the commits immediately before it if the change itself looks harmless. The bug is usually either in the identified commit or in a nearby one that set up the conditions.

Found this useful? SysEmperor has more Git tutorials and free developer tools at sysemperor.com — including a SQL Table Editor, chmod Calculator, and downloadable AI skills for Claude.

tmux: Persistent Terminal Sessions for Developers

Sysemperor — Tue, 19 May 2026 05:05:25 +0000

I lost three hours of work to a dropped SSH connection before I learned about tmux. One detached session later and that problem stopped existing entirely. If you spend any meaningful time on remote servers, tmux is the single highest-leverage tool you can add to your workflow.

Two things make it worth learning: sessions survive after you close your terminal or lose an SSH connection — your processes keep running and you reconnect to find everything exactly where you left it. And you can split a single terminal into multiple panes and windows without juggling tabs.

Install

# Debian / Ubuntu
sudo apt install tmux

# RHEL / Fedora / Rocky
sudo dnf install tmux

# macOS
brew install tmux

Core concepts

tmux has three levels:

Session — a collection of windows. One session per project is the natural fit.
Window — a full-screen view inside a session. Think of it like a browser tab.
Pane — a split region within a window. One window can hold several panes.

The prefix key is how you send commands to tmux without the keystrokes going to the program running inside it. The default is Ctrl+B. Press it, release, then press the command key.

Start and attach to sessions

Create a new named session:

tmux new -s myproject

Detach (session keeps running in the background):

Ctrl+B  d

List sessions:

tmux ls

Reattach by name:

tmux attach -t myproject

Short form: tmux a -t myproject. With only one session, tmux a is enough.

Kill a session:

tmux kill-session -t myproject

Windows

Action	Keys
New window	`Ctrl+B c`
Next window	`Ctrl+B n`
Previous window	`Ctrl+B p`
Go to window by number	`Ctrl+B 0–9`
Rename current window	`Ctrl+B ,`
Close current window	`Ctrl+B &`

Windows appear in the status bar at the bottom. The active one has a * next to its name.

Panes

Action	Keys
Split top/bottom	`Ctrl+B "`
Split left/right	`Ctrl+B %`
Move between panes	`Ctrl+B arrow keys`
Resize pane	`Ctrl+B Ctrl+arrow keys`
Zoom to full screen	`Ctrl+B z` (toggle)
Close current pane	`Ctrl+B x`

Zoom is one of the most useful shortcuts — it temporarily expands a pane to fill the entire window without closing the others. Hit it again to return to the split view.

Scrollback and copy mode

Mouse scroll does not work inside tmux by default. To scroll:

Ctrl+B  [

This enters copy mode. Arrow keys and Page Up/Page Down navigate. Press / to search, n for the next match, q to exit.

Auto-start a session on login

tmux sessions do not survive a reboot. For development machines where you always want a session waiting:

# add to ~/.bashrc or ~/.zshrc
if [ -z "$TMUX" ]; then
  tmux attach -t main 2>/dev/null || tmux new -s main
fi

The [ -z "$TMUX" ] guard prevents tmux from launching inside an existing tmux session, which would nest them.

~/.tmux.conf

A minimal config that most people find immediately useful:

# Start window and pane numbering at 1 instead of 0
set -g base-index 1
setw -g pane-base-index 1

# Enable mouse: click to focus panes, drag to resize
set -g mouse on

# Increase scrollback
set -g history-limit 10000

# Status bar: show session name on the left, time on the right
set -g status-left "[#S] "
set -g status-right "%H:%M"

Reload the config without restarting:

Ctrl+B  :source-file ~/.tmux.conf

Mouse support is the single option worth enabling immediately if you are used to a GUI terminal. It makes pane navigation and resizing click-based while you build up the keyboard shortcuts.

Found this useful? SysEmperor has more Linux tutorials and free developer tools — including a Cron Visual Editor, fstab Editor, and a growing library of downloadable AI skills at sysemperor.com.

AI Isn't Replacing Programmers. It's Replacing the OS.

Sysemperor — Sat, 09 May 2026 12:50:32 +0000

The tech world is having a collective anxiety attack about AI. Every week there is a new think-piece about which jobs will disappear first, which languages will become obsolete, and whether learning to code still means anything. Most of this conversation is missing the point entirely.

We're a small team at SysEmperor, but we agree on one thing: AI is not replacing programmers. It is replacing the operating system.

Think about what an OS actually does

An operating system is, at its core, a general-purpose interface between you and raw computing power. It does not do anything specific by default. It sits there, capable of anything — processing files, running servers, drawing interfaces, connecting to networks — waiting for the right input.

Give it the right software and it becomes a video editor. Give it different software and it becomes a database server. Give it a compiler and a blank file and you can build whatever you want from scratch. The OS is a box of infinite potential. What you get out depends entirely on what you put in.

Sound familiar?

AI is that same box

A large language model, by itself, does nothing specific. It sits there, capable of almost anything — writing code, analyzing documents, generating content, reasoning through problems — waiting for the right input.

Give it the right prompt and it becomes a data analyst. Give it a different prompt and it becomes a legal document reviewer. Give it a well-crafted system prompt and a set of tools and you have built something that would have taken months to code from scratch.

The parallel is not metaphorical. It is structural. An OS exposes raw compute. An LLM exposes raw intelligence. In both cases, the interface determines everything you actually get out of it.

Software was the previous abstraction layer

When operating systems became mainstream, a new layer emerged: software. Most people could not write assembly or C. They did not need to. Microsoft Word handled documents. Excel handled numbers. Photoshop handled images.

Software abstracted away the complexity of the OS. You no longer needed to understand file systems to edit a photo. The software handled the interface; the OS handled the hardware. Millions of people became productive without writing a single line of code.

But this abstraction had a cost. Software is rigid. It does what its developers built it to do, within the boundaries they defined. If you needed something slightly different, you were stuck. The power of the underlying OS was there — but inaccessible without programming skills.

Prompt engineering is the next abstraction layer

What programming was to the OS, prompt engineering is to AI. It is the method by which someone can unlock the full capability of the platform beneath them.

A well-engineered prompt is not just a question. It defines context, constraints, output format, and reasoning approach. It can encode complex workflows, handle edge cases, and produce consistent results across thousands of uses. Done well, a prompt can replace what would previously have required a custom application — months of development, a team of engineers, ongoing maintenance.

We are already watching this play out. The first wave of SaaS services being disrupted is not coincidental. When a well-structured prompt can perform the core function of a single-purpose tool, that tool stops being worth paying for. Not for everything, not yet — but the direction is clear and the pace is accelerating.

But not everyone will write good prompts — and that is the whole point

Here is the part most people skip.

Not everyone could program. That is exactly why software existed in the first place. The OS could theoretically do anything, but most people needed someone to package that capability into something usable. Developers built those packages. Everyone else bought and ran them.

The same dynamic is already playing out with AI. The raw capability of a language model is technically accessible to anyone with an API key. In practice, writing a complex, reliable, well-scoped prompt that performs a specific professional workflow consistently — and keeps working as models update — is a real skill. Not everyone will develop it. Not everyone will want to.

There will be a class of people fluent in this new language. And there will be a much larger class of people who want the output without the craft. That second group needs packaged prompts. They need what software was: someone else's expertise, ready to use.

Skills are the new software

This is the thesis we are building on at SysEmperor.

Ready-to-use AI skills — carefully crafted system prompts with defined roles, constraints, and behaviours, packaged for immediate use — will become as common and as necessary as software packages are today. Not because AI is hard to use in a basic sense, but because using it well, consistently, for a specific professional purpose, requires real work that most people reasonably do not want to do themselves.

The analogy holds all the way down. Software licenses are expensive for the same reason that some tasks will not be worth spending AI credits on — some people will still reach for a SaaS tool or a traditional application, for the same reason some developers still hand-code things they could automate. A more capable layer does not eliminate every option below it. It just changes which layer most people choose to operate at.

That's why we started to offer a growing library of skills for Claude — downloadable, ready to use, no prompt engineering required. Browse the skills →

This is not chaos. It is a layer shift.

Every time a new abstraction layer emerged in computing, the same alarm bells rang. Compilers would make assembly programmers obsolete. GUIs would kill the command line. SaaS would destroy on-premise software. Web apps would make native developers irrelevant.

Each time, the layer below did not vanish. It moved down the stack. Used by fewer people directly, but no less essential to everything built on top.

The requirements from users have not changed either. People need to write things, analyze data, manage projects, communicate, build products. The underlying human needs are identical to what they were in 1995.

What changes is the layer you use to meet those needs. That layer is shifting again. The interface is changing. The demands are not.

AI is not bringing the chaos that some headlines are selling. It is the next iteration of a pattern that has repeated consistently since the first personal computer sat on a desk: raw capability, then an abstraction layer, then packaged tools for everyone who does not want to work at the abstraction layer directly.

We have been here before. We know how this goes. The only question is which layer you want to work at — and whether you get there early enough to matter.

This post is from the team at SysEmperor — a free toolkit for developers and sysadmins, with a growing library of downloadable AI skills for Claude. We also publish practical tutorials on Linux, DevOps, Git, PostgreSQL, and more.