DEV Community: Ahmed Raza Idrisi

# 🔬 PostgreSQL Internals: What Is Actually Inside an 8 KB Page?

Ahmed Raza Idrisi — Sat, 08 Aug 2026 08:01:33 +0000

In my previous post, I looked at what happens when PostgreSQL executes a SELECT query.

One part of that journey caught my attention:

PostgreSQL doesn't simply read "rows" from disk. It works with pages.

So I wanted to go one level deeper.

What is actually inside a PostgreSQL page?

Today, we're going to inspect one.

Not just with a diagram.

We'll use PostgreSQL itself to look inside its storage.

🧠 First: What Is a PostgreSQL Page?

PostgreSQL stores table and index data in fixed-size blocks called pages.

In a standard PostgreSQL build, a page is:

8 KB

So instead of imagining a table like this:

users

Row 1
Row 2
Row 3
Row 4
Row 5
...

Think about it more like:

users table

┌──────────────────┐
│ Page 0 - 8 KB    │
├──────────────────┤
│ Page 1 - 8 KB    │
├──────────────────┤
│ Page 2 - 8 KB    │
├──────────────────┤
│ Page 3 - 8 KB    │
└──────────────────┘

Each page can contain multiple tuples (PostgreSQL's internal term for stored row versions).

🔍 Why Does PostgreSQL Use Pages?

Imagine PostgreSQL had to read every individual row directly from disk.

That would create a huge amount of I/O.

Instead, PostgreSQL works with blocks of data.

If it needs a particular piece of data, it can bring the relevant page into memory.

A simplified view is:

Disk
 │
 │ 8 KB page
 ▼
PostgreSQL Buffer
 │
 ▼
Executor
 │
 ▼
Tuple

This is one reason database performance is heavily influenced by I/O.

🧱 What's Inside a Page?

A simplified PostgreSQL heap page looks something like this:

┌──────────────────────────────┐
│        Page Header           │
├──────────────────────────────┤
│        Line Pointers         │
│                              │
│                              │
│        Free Space            │
│                              │
│                              │
│        Tuples / Rows         │
└──────────────────────────────┘

There are several important pieces here.

1️⃣ Page Header

Every page has a header containing metadata about the page.

Among other things, PostgreSQL tracks information such as:

page state
free space boundaries
LSN-related information
checksum-related information when enabled

The important idea is:

The page needs metadata so PostgreSQL knows how to manage the data inside it.

2️⃣ Line Pointers

This is one of the most interesting parts.

PostgreSQL doesn't simply say:

Row 1 starts at byte 100
Row 2 starts at byte 250

Instead, the page contains line pointers (also called item identifiers).

Conceptually:

Line Pointer 1 → Tuple 1
Line Pointer 2 → Tuple 2
Line Pointer 3 → Tuple 3

This becomes particularly important when PostgreSQL updates rows.

We'll come back to this when we discuss MVCC.

3️⃣ Free Space

A page needs somewhere to put new tuples.

So there is free space between the line-pointer area and tuple storage.

Conceptually:

┌─────────────────────┐
│ Page Header         │
├─────────────────────┤
│ Line Pointers       │
├─────────────────────┤
│                     │
│     Free Space      │
│                     │
├─────────────────────┤
│ Tuple 3             │
│ Tuple 2             │
│ Tuple 1             │
└─────────────────────┘

The exact physical layout is more nuanced, but this mental model is useful.

4️⃣ Tuples

Finally, we have the actual stored row versions.

For example:

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT
);

Insert some data:

INSERT INTO users (name)
VALUES
    ('Ahmed'),
    ('John'),
    ('Sarah'),
    ('Mike');

These rows eventually occupy storage inside heap pages.

🧪 Let's Inspect One

Now let's get our hands dirty.

PostgreSQL provides an extension called:

pageinspect

It provides functions for inspecting the internal contents of database pages.

⚠️ This is primarily a learning/debugging tool. You generally don't need it for normal application development.

Step 1: Enable `pageinspect`

Run:

CREATE EXTENSION pageinspect;

You may need appropriate privileges to create the extension.

Step 2: Create a Test Table

Let's create a small table:

CREATE TABLE page_demo (
    id SERIAL PRIMARY KEY,
    name TEXT
);

Insert some rows:

INSERT INTO page_demo (name)
VALUES
    ('Ahmed'),
    ('John'),
    ('Sarah'),
    ('Mike'),
    ('David');

Step 3: Find the Table's Physical Relation

PostgreSQL stores table data in a physical relation.

We can ask PostgreSQL for the relation's file node:

SELECT pg_relation_filenode('page_demo');

You'll get a number similar to:

This is an internal identifier used by PostgreSQL's storage system.

Step 4: Inspect the Page Header

Now let's inspect the first page:

SELECT *
FROM page_header(
    get_raw_page('page_demo', 0)
);

You'll see information about the page.

For example, you'll encounter fields such as:

lsn
checksum
flags
lower
upper
special
pagesize
version
prune_xid

The exact values depend on your PostgreSQL version and table.

🧐 What Does `pagesize` Tell Us?

You should see a value corresponding to the page size, typically:

That's:

8192 bytes
÷ 1024
=
8 KB

So we can actually inspect the page and see its size.

Step 5: Inspect the Line Pointers

Now let's inspect the items stored on the page:

SELECT *
FROM heap_page_items(
    get_raw_page('page_demo', 0)
);

This is where things start getting interesting.

You'll see information associated with tuples and their positions on the page.

Some of the columns you'll encounter include things such as:

lp
lp_off
lp_flags
lp_len
t_xmin
t_xmax
t_ctid

Don't worry if these look strange.

They're the building blocks of PostgreSQL's storage engine.

🔥 One Column You Should Remember: `t_ctid`

You'll see something like:

(0,1)
(0,2)
(0,3)

These values are related to the tuple's physical location.

The general idea is:

(block number, offset number)

For example:

(0,3)

can be thought of as:

Page 0
Line Pointer 3

This is called a CTID.

🧪 Let's Look at CTID From SQL

We can query:

SELECT
    ctid,
    id,
    name
FROM page_demo;

You might see:

 ctid   | id | name
--------+----+-------
 (0,1)  | 1  | Ahmed
 (0,2)  | 2  | John
 (0,3)  | 3  | Sarah
 (0,4)  | 4  | Mike
 (0,5)  | 5  | David

The exact values aren't guaranteed to look exactly like this on every table/database state, but the important concept is the same.

🤯 Here's Where It Gets Interesting

Let's update a row.

UPDATE page_demo
SET name = 'Ahmed Updated'
WHERE id = 1;

Now check:

SELECT
    ctid,
    id,
    name
FROM page_demo
WHERE id = 1;

You may notice that the ctid has changed.

Why?

Because PostgreSQL uses MVCC.

An UPDATE isn't simply:

Old row
   ↓
Overwrite
   ↓
New row

Internally, PostgreSQL creates a new row version and marks the old version as no longer visible to appropriate transactions.

This is one of the reasons understanding pages is so important.

We'll explore this properly in the next article.

🧠 So What Have We Learned?

A PostgreSQL table isn't simply a collection of rows.

A simplified mental model is:

Database
   │
   ▼
Table
   │
   ▼
Pages
   │
   ▼
Line Pointers
   │
   ▼
Tuples

And the page itself contains structures that help PostgreSQL manage those tuples.

🚨 Why Should Backend Developers Care?

You might be thinking:

"I'm a Laravel/Go developer. Why should I care about 8 KB pages?"

Because these internals explain things you encounter at the application level.

For example:

Why does UPDATE sometimes create table bloat?

MVCC + tuple versions.

Why does VACUUM exist?

Because old tuple versions eventually need cleanup.

Why can an UPDATE cause more I/O than expected?

Because PostgreSQL may need to create a new tuple version and update related structures.

Why do indexes matter?

Because indexes can reduce the amount of table data/pages PostgreSQL needs to visit.

Why can queries become slower as a table grows?

Because the number of pages that need to be processed can increase.

These aren't random PostgreSQL behaviors.

They come from the storage architecture.

🧩 The Bigger Picture

We're slowly connecting the dots:

                PostgreSQL
                    │
        ┌───────────┴───────────┐
        │                       │
     Query                    Storage
     Layer                      Layer
        │                       │
     Planner                  Pages
        │                       │
     Executor                 Tuples
        │                       │
        └───────────┬───────────┘
                    │
                   MVCC
                    │
              VACUUM / WAL

Understanding one piece makes the next piece easier.

🔥 Final Takeaway

The next time you write:

SELECT *
FROM users
WHERE id = 10;

remember that PostgreSQL isn't just "looking for a row."

It is working through:

Query
 ↓
Execution Plan
 ↓
Relation
 ↓
Page
 ↓
Line Pointer
 ↓
Tuple
 ↓
Visibility
 ↓
Result

And that is just the beginning.

🚀 What's Next?

Now that we know what a PostgreSQL page looks like, the next question becomes much more interesting:

What happens internally when we UPDATE a row?

That's where we'll get into:

MVCC
xmin
xmax
tuple versions
dead tuples
visibility
why PostgreSQL doesn't overwrite rows in place

That's where PostgreSQL internals really start to click.

I'm learning PostgreSQL internals by going below the SQL layer and documenting what I find along the way.

If you're learning PostgreSQL too, follow along. 🚀

# 🔍 What Actually Happens When PostgreSQL Executes a SELECT Query?

Ahmed Raza Idrisi — Sat, 08 Aug 2026 07:21:23 +0000

When we write:

SELECT *
FROM users
WHERE id = 100;

it looks incredibly simple.

We send SQL.

PostgreSQL gives us rows.

But what actually happens between those two steps?

There is a lot going on internally.

Understanding this process changed the way I think about database performance.

Instead of thinking:

"I wrote a query and PostgreSQL executed it."

I started thinking:

"What path does PostgreSQL take to turn my SQL into actual data?"

Let's follow that journey.

🧭 The High-Level Journey

A simplified version looks like this:

             SQL Query
                 │
                 ▼
              Parser
                 │
                 ▼
            Parse Tree
                 │
                 ▼
        Analyzer / Rewriter
                 │
                 ▼
           Query Planner
                 │
                 ▼
          Execution Plan
                 │
                 ▼
             Executor
                 │
                 ▼
          Buffer Manager
                 │
          ┌──────┴──────┐
          ▼             ▼
     Shared Buffers    Disk
          │             │
          └──────┬──────┘
                 ▼
              Rows

Let's break this down.

1. The Client Sends SQL

Suppose our application sends:

SELECT id, name
FROM users
WHERE id = 100;

The PostgreSQL server receives this SQL statement.

At this point, PostgreSQL doesn't immediately start reading rows from the table.

First, it needs to understand what we wrote.

2. Parser: "What Did You Write?"

The parser checks whether the SQL is syntactically valid.

For example:

SELECT id, name
FROM users
WHERE id = 100;

is valid.

But:

SELEC id name
FROM users;

is not valid SQL syntax.

The parser builds an internal representation called a parse tree.

You can think of it as PostgreSQL converting:

SELECT
   ↓
columns
   ↓
table
   ↓
condition

into a structure the database can work with.

3. Analyzer: "What Do These Names Mean?"

Now PostgreSQL needs to understand the objects referenced by the query.

For example:

FROM users

Does the users table actually exist?

And:

SELECT name

Does the name column exist?

PostgreSQL resolves things such as:

table names
column names
data types
functions
operators

If we write:

SELECT something
FROM users;

and something doesn't exist, PostgreSQL will reject the query.

4. Rewriting

PostgreSQL can transform the query before planning it.

This stage is particularly important for things such as:

views
rules
some query transformations

For a simple query, you might not notice this stage.

But internally, PostgreSQL can rewrite the query into another representation that is easier to plan and execute.

5. The Query Planner

Now things get interesting.

PostgreSQL needs to decide:

"What's the cheapest way to execute this query?"

Suppose we have:

SELECT *
FROM users
WHERE email = 'user@example.com';

PostgreSQL might have several possible strategies.

Option 1: Sequential Scan

Read the table from beginning to end.

Row 1
Row 2
Row 3
Row 4
...
Row 1,000,000

Option 2: Index Scan

If an appropriate index exists:

CREATE INDEX idx_users_email
ON users(email);

PostgreSQL may use the index to locate the matching row much more efficiently.

The planner compares possible execution strategies using estimated costs.

6. EXPLAIN Lets Us See the Plan

We can ask PostgreSQL what it intends to do:

EXPLAIN
SELECT *
FROM users
WHERE email = 'user@example.com';

You might see something like:

Index Scan using idx_users_email on users
  Index Cond: (email = 'user@example.com')

Now we have a window into the planner's decision.

This is one reason EXPLAIN is such an important tool for backend developers.

7. The Executor Takes Over

The planner creates an execution plan.

The executor then actually runs that plan.

For example:

Index Scan
    ↓
Find matching index entry
    ↓
Locate table row
    ↓
Return row

The executor is responsible for producing the actual result.

8. But Where Is the Data?

This is where PostgreSQL's storage internals become important.

The table data ultimately lives on disk.

But PostgreSQL doesn't simply perform a disk read for every row.

That would be extremely expensive.

Instead, PostgreSQL uses a buffer cache.

One important component involved here is:

shared_buffers

These are PostgreSQL's shared memory buffers used to cache data pages.

9. PostgreSQL Works With Pages

PostgreSQL doesn't think of a table simply as:

User 1
User 2
User 3
User 4

Internally, table data is organized into fixed-size pages.

A PostgreSQL page is normally:

8 KB

So conceptually:

Table
│
├── Page 0
├── Page 1
├── Page 2
├── Page 3
└── ...

Each page contains multiple tuples/rows depending on their size.

This is one of the most important concepts to understand before diving into PostgreSQL internals.

10. Buffer Hit vs Disk Read

Suppose PostgreSQL needs a page.

First, it can check whether that page is already available in memory.

If it is:

Query
 ↓
Buffer Manager
 ↓
Page already in memory
 ↓
Buffer Hit

Much faster.

If it isn't:

Query
 ↓
Buffer Manager
 ↓
Page not in memory
 ↓
Read from disk
 ↓
Put page into buffer
 ↓
Use the data

This is why memory and I/O have such a significant effect on database performance.

11. What Happens With Our Indexed Query?

Let's put everything together.

We execute:

SELECT id, name
FROM users
WHERE email = 'user@example.com';

Suppose we have:

CREATE INDEX idx_users_email
ON users(email);

A simplified execution might look like:

SQL
 │
 ▼
Parser
 │
 ▼
Analyzer
 │
 ▼
Planner
 │
 │
 ├── Sequential Scan?
 │
 └── Index Scan?  ← selected
 │
 ▼
Executor
 │
 ▼
Index
 │
 ▼
Find matching tuple location
 │
 ▼
Check required table page
 │
 ├── Buffer Hit
 │
 └── Disk Read
 │
 ▼
Return row

That's quite a journey for one simple SELECT.

12. Why Should Application Developers Care?

Because database internals directly affect application performance.

Consider two queries:

SELECT *
FROM orders
WHERE customer_id = 100;

and:

SELECT id, total, status
FROM orders
WHERE customer_id = 100;

The difference isn't simply about SQL style.

It can affect:

amount of data read
memory usage
network traffic
CPU usage
serialization
index usage
overall API latency

Understanding what's happening underneath helps us make better decisions.

13. A Simple Mental Model

When debugging a slow PostgreSQL query, I now think about it in this order:

1. What SQL did I write?
          ↓
2. How did PostgreSQL parse it?
          ↓
3. What execution plan did PostgreSQL choose?
          ↓
4. Is it using an index?
          ↓
5. How many rows/pages are being processed?
          ↓
6. Are pages already in memory?
          ↓
7. How much disk I/O is happening?
          ↓
8. Is the planner's estimate accurate?

This is much more useful than blindly adding indexes.

🔥 The Most Important Lesson

A database isn't just:

SQL → Result

There is a whole execution pipeline between them:

SQL
 ↓
Parser
 ↓
Analyzer / Rewriter
 ↓
Planner
 ↓
Execution Plan
 ↓
Executor
 ↓
Buffer Manager
 ↓
Pages
 ↓
Disk / Memory
 ↓
Result

Once you understand this pipeline, concepts like:

indexes
EXPLAIN ANALYZE
shared buffers
sequential scans
index scans
MVCC
VACUUM
WAL

start making much more sense.

🚀 What's Next?

This is only the beginning.

If you're also learning PostgreSQL internals, follow along. I'm documenting the concepts as I learn them and trying to explain them without assuming you're already a database expert.

🚀 How I Optimize Slow MySQL Queries in Laravel: My Practical Checklist

Ahmed Raza Idrisi — Tue, 14 Jul 2026 09:48:27 +0000

One of the most common questions I hear is:

"My API is slow. Where do I start?"

The first instinct is usually:

Upgrade the server
Increase CPU
Add more RAM

But in many cases, the database query is the real bottleneck.

Whenever I investigate a slow Laravel application, I follow the same checklist. It helps me identify performance issues before making unnecessary infrastructure changes.

Let's go through it.

1️⃣ Find the Slow Queries First

Don't start optimizing random queries.

Start with the queries that are executed the most or take the most time.

Useful tools:

Laravel Telescope
Laravel Debugbar (development)
MySQL Slow Query Log
Application Performance Monitoring (APM)

You can't optimize what you haven't measured.

2️⃣ Stop Using `SELECT *`

One of the easiest improvements.

❌ Instead of:

SELECT *
FROM users
WHERE id = 10;

Use:

SELECT id, name, email
FROM users
WHERE id = 10;

Why?

Less data transferred
Lower memory usage
Faster response
Easier for MySQL to use covering indexes

Only fetch the columns your application actually needs.

3️⃣ Always Check the Execution Plan

Before changing anything, run:

EXPLAIN
SELECT id, name
FROM users
WHERE email = 'john@example.com';

Things I usually look for:

Is MySQL scanning the whole table?
Is an index being used?
How many rows are examined?
Is there a temporary table?
Is filesort being used?

EXPLAIN often tells you exactly why a query is slow.

4️⃣ Verify Your Indexes

Indexes are one of the biggest performance improvements you can make—but only when they match your queries.

Example:

SELECT *
FROM orders
WHERE customer_id = 100;

Create an index:

CREATE INDEX idx_customer_id
ON orders(customer_id);

Now MySQL can jump directly to the matching rows instead of scanning the entire table.

5️⃣ Look for Composite Index Opportunities

Suppose your query is:

SELECT id, total
FROM orders
WHERE customer_id = 10
AND status = 'paid';

Instead of two separate indexes:

customer_id
status

A composite index is often better:

CREATE INDEX idx_customer_status
ON orders(customer_id, status);

Remember:

The order of columns inside a composite index matters.

6️⃣ Avoid Functions in the WHERE Clause

This prevents MySQL from using indexes efficiently.

❌ Bad:

SELECT *
FROM users
WHERE YEAR(created_at) = 2026;

Better:

SELECT *
FROM users
WHERE created_at >= '2026-01-01'
AND created_at < '2027-01-01';

Now MySQL can use an index on created_at.

7️⃣ Watch for N+1 Queries

This is one of the most common Laravel performance problems.

❌ Example:

$users = User::all();

foreach ($users as $user) {
    echo $user->posts;
}

This may execute:

1 query for users
N queries for posts

Instead, eager load the relationship:

$users = User::with('posts')->get();

Much fewer database queries.

8️⃣ Cache Frequently Used Data

Not every request needs to hit the database.

For data that changes infrequently, caching can dramatically reduce database load.

Example with Laravel:

$users = Cache::remember(
    'users',
    300,
    fn () => User::all()
);

The first request reads from the database.

Subsequent requests are served from the cache until it expires.

9️⃣ Add Pagination

Fetching thousands of rows at once is rarely necessary.

Instead of:

User::all();

Use:

User::paginate(20);

Benefits:

Faster queries
Smaller responses
Better user experience

🔟 Measure Again

Optimization isn't finished after adding an index.

Measure the results.

Compare:

Query execution time
Number of rows scanned
API response time
CPU usage
Database load

Always verify that your changes actually improved performance.

My Personal Optimization Workflow

Slow API

↓

Identify the slow query

↓

Run EXPLAIN

↓

Check indexes

↓

Remove SELECT *

↓

Look for N+1 queries

↓

Cache frequently accessed data

↓

Measure again

Final Thoughts

Performance optimization isn't about applying every trick you know.

It's about understanding why a query is slow and making targeted improvements.

Most of the biggest gains I've seen came from simple changes like:

Selecting only the required columns
Adding the right index
Eliminating N+1 queries
Caching frequently requested data

Small optimizations, applied consistently, can have a huge impact on application performance.

What are your go-to techniques for optimizing slow MySQL queries? I'd love to hear your approach in the comments.

# 🎉 Happy Birthday, PHP! 🎂

Ahmed Raza Idrisi — Wed, 10 Jun 2026 18:34:45 +0000

On June 8th, we celebrate another year of PHP—the language that transformed my career from writing simple CRUD applications to building enterprise-grade systems used by thousands of users.

Over the last few years, PHP has enabled me to build:

✅ Insurance API integrations with multiple providers
✅ Enterprise-scale applications
✅ Customer and business dashboards
✅ Standalone REST APIs and microservices
✅ PDF generation and document automation systems
✅ AI-powered application features
✅ School and hotel management solutions
✅ High-performance applications with Laravel, OpenSwoole, and FrankenPHP

What I admire most about PHP is its evolution. The PHP of today is not the PHP people joked about years ago.

Modern PHP offers:

Strong typing
Enums and Attributes
Fibers for async programming
Improved performance
Excellent tooling
A mature ecosystem

Combined with frameworks like Laravel and Symfony, PHP remains one of the most productive technologies for building real-world business applications.

From handling millions of API requests to powering enterprise workflows, PHP continues to prove its reliability every day.

A big thank you to Rasmus Lerdorf, the PHP core team, and the entire open-source community for making this ecosystem what it is today.

Happy Birthday, PHP! 🎉

What's the most interesting project you've built with PHP?

Why 1 Million GoRoutines Don't Use Your GPU: Understanding CPUs, GPUs, Go's GMP Scheduler, and GPU Computing

Ahmed Raza Idrisi — Tue, 02 Jun 2026 13:37:43 +0000

Article Goal:
Write a deep technical article for software engineers explaining why millions of Go goroutines still execute on CPU cores instead of GPU cores, even though both ultimately process binary instructions. The article should start from first principles and progressively build understanding of CPU architecture, GPU architecture, Go's GMP scheduler, operating system threads, concurrency vs parallelism, and GPU computing.

Sections to Cover

1. Introduction

Discuss a common misconception:

"If a GPU has thousands of cores and Go can create millions of goroutines, why doesn't Go automatically run goroutines on the GPU?"

Introduce the core idea:

Goroutines run on CPU threads.
GPUs are specialized compute devices.
Concurrency is different from GPU parallelism.

2. Understanding CPU Architecture

Explain:

Modern CPUs (Intel i5, i7, AMD Ryzen).
Small number of powerful cores.
Branch prediction.
Large caches.
Out-of-order execution.
Context switching.

Include diagram:

CPU
├── Core 1
├── Core 2
├── Core 3
└── Core 4

Discuss why CPUs excel at:

APIs
Databases
Filesystems
Operating system tasks
Business logic

3. Understanding GPU Architecture

Explain:

NVIDIA RTX 4090
CUDA cores
Streaming Multiprocessors
Massive parallelism
Throughput-oriented design

Diagram:

GPU
├── SM 1
│   ├── 100s of threads
├── SM 2
│   ├── 100s of threads
...
└── SM N

Discuss why GPUs excel at:

Matrix multiplication
AI
Simulations
Image processing
Scientific computing

4. Go's GMP Scheduler Explained

Explain:

G = Goroutine

M = Machine (OS Thread)

P = Processor (Logical Scheduler)

Diagram:

1,000,000 Goroutines
        ↓
 Go Scheduler
        ↓
     P Pool
        ↓
    M Threads
        ↓
    CPU Cores

Clarify:

P is NOT a GPU processor.
P is a scheduling context inside Go runtime.

5. What Happens When You Launch One Million Goroutines

Example:

for i := 0; i < 1000000; i++ {
    go worker(i)
}

Explain:

Go does not create 1 million OS threads.
Goroutines are multiplexed onto a small number of CPU threads.
Scheduler performs work stealing.
Lightweight stack allocation.

Memory comparison:

OS Thread ≈ 1MB–8MB
Goroutine ≈ 2KB initial stack

6. Why API Calls Don't Benefit From GPUs

Example:

go fetchMarketData()

Break down:

DNS
TCP
TLS
Socket operations
Waiting for remote server

Timeline:

CPU Work: 0.5ms
Network Wait: 99.5ms

Explain why GPU acceleration provides no benefit.

7. When GPUs Actually Shine

Examples:

Black-Scholes calculations
Greeks calculations
Monte Carlo simulations
Option chain analytics
Risk analysis
AI trading models

Diagram:

1 Million Option Contracts
        ↓
GPU Threads
        ↓
Delta
Gamma
Theta
Vega

8. Go + CUDA Architecture

Show architecture:

Go
├── Market Data
├── APIs
├── WebSockets
├── Risk Engine
└── GPU Dispatcher
          ↓
      CUDA
          ↓
        RTX 4090

Explain that Go orchestrates work while CUDA executes calculations.

9. Python vs Go vs Rust for GPU Workloads

Compare:

Language	CPU Performance	GPU Integration	Typical Use
Python	Low	Excellent	AI/ML
Go	High	Limited	Services
Rust	Very High	Growing	Systems
C++	Maximum	Native	HPC

Explain that most Python GPU workloads ultimately execute C++/CUDA kernels.

10. Real Trading System Architecture

Design a production-grade option screener:

Market Feed
      ↓
Go Services
      ↓
Kafka
      ↓
GPU Cluster
      ↓
Risk Engine
      ↓
Trade Signals
      ↓
Execution Engine

Discuss:

Scalability
Latency
GPU utilization
Cost considerations

11. Key Takeaways

Summarize:

Goroutines run on CPUs.
GMP's P is not a GPU processor.
GPUs are not replacements for CPUs.
GPUs accelerate mathematical workloads.
Go is excellent for orchestration.
CUDA/Rust/C++ are used for extreme numerical workloads.
Modern trading systems combine CPU concurrency and GPU acceleration.

Using Redis for API Caching in Go (Speed Up Your Backend)

Ahmed Raza Idrisi — Sat, 09 May 2026 13:15:34 +0000

After building APIs in Go, the next big question is:

👉 How do you make them faster?

This is where Redis comes in.

In this post, we’ll:

Connect Go with Redis
Cache API responses
Reduce database load
Improve performance

🧠 What is Redis?

Redis is an in-memory database used for:

Caching
Sessions
Queues
Real-time systems

Think of Redis like:
👉 “Super-fast temporary storage”

Instead of hitting PostgreSQL every time:

First request → DB
Next requests → Redis cache ⚡

⚙️ Install Redis Package

```bash id="gq78f0"
go get github.com/redis/go-redis/v9




---

## 📦 Connect Redis



```go id="lb7m2n"
package main

import (
    "context"
    "github.com/redis/go-redis/v9"
)

var ctx = context.Background()

var rdb = redis.NewClient(&redis.Options{
    Addr: "localhost:6379",
})

🗄️ Example API Response

Normally:

```go id="1h9v4t"
func getUsersFromDB() string {
return "Users from PostgreSQL"
}




But hitting DB repeatedly is expensive.

---

## ⚡ Add Redis Caching



```go id="h4m92g"
func getUsers(w http.ResponseWriter, r *http.Request) {

    cachedData, err := rdb.Get(ctx, "users").Result()

    if err == nil {
        w.Write([]byte("Cache Hit 🚀\n" + cachedData))
        return
    }

    data := getUsersFromDB()

    rdb.Set(ctx, "users", data, time.Minute*5)

    w.Write([]byte("DB Hit 🐘\n" + data))
}

🔥 What’s Happening Here?

First Request

Redis has no data
Fetch from DB
Store in Redis

Next Requests

Redis already has data
Return instantly ⚡

📊 Why Caching Matters

Without cache:

Client → API → Database

With cache:

Client → API → Redis ⚡
             ↓
          Database (less often)

🚀 Benefits of Redis

Faster APIs
Reduced DB load
Better scalability
Improved user experience

⚠️ Important Production Notes

Don’t cache forever.

Always:

Set expiration time
Clear cache after updates
Avoid stale data

🧭 Real-World Usage

Redis is used in:

Authentication systems
Rate limiting
API caching
Queues
Real-time apps

Companies like:

Netflix
Instagram
Twitter

use Redis heavily.

💬 Final Thought

Caching is one of the easiest ways to improve backend performance.

You don’t always need:

Bigger servers
More CPUs

Sometimes…
👉 You just need smarter architecture.

🚀 Coming Next

👉 Rate Limiting in Go API
👉 Background Jobs with Redis
👉 Redis Pub/Sub in Go

Structuring a Go API Like Laravel (Controller, Service, Repository)

Ahmed Raza Idrisi — Mon, 04 May 2026 11:39:24 +0000

If you're coming from Laravel, one thing feels missing in Go:

👉 Structure

By default, Go gives you freedom—but no clear architecture.

So in this post, we’ll structure a Go API like Laravel:

Controller → Handle request
Service → Business logic
Repository → Database

🧠 Why Structure Matters

Without structure:

Code becomes messy quickly
Hard to scale
Difficult to debug

With structure:

Clean separation of concerns
Easier testing
Production-ready codebase

📁 Folder Structure

project/
 ├── main.go
 ├── controller/
 ├── service/
 ├── repository/
 ├── model/

🧱 Model (model/user.go)

```go id="6pn1u5"
package model

type User struct {
ID int json:"id"
Name string json:"name"
}




---

## 🗄️ Repository Layer

Handles database queries



```go id="aq1u8u"
package repository

import (
    "database/sql"
    "yourapp/model"
)

type UserRepository struct {
    DB *sql.DB
}

func (r *UserRepository) GetAll() ([]model.User, error) {
    rows, err := r.DB.Query("SELECT id, name FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []model.User

    for rows.Next() {
        var user model.User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    return users, nil
}

⚙️ Service Layer

Handles business logic

```go id="qf1kmz"
package service

import (
"yourapp/model"
"yourapp/repository"
)

type UserService struct {
Repo *repository.UserRepository
}

func (s *UserService) GetUsers() ([]model.User, error) {
return s.Repo.GetAll()
}




---

## 🌐 Controller Layer

Handles HTTP requests



```go id="n8t1rn"
package controller

import (
    "encoding/json"
    "net/http"
    "yourapp/service"
)

type UserController struct {
    Service *service.UserService
}

func (c *UserController) GetUsers(w http.ResponseWriter, r *http.Request) {
    users, err := c.Service.GetUsers()
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(users)
}

🚀 main.go (Wire Everything)

```go id="b4r8f2"
package main

import (
"database/sql"
"log"
"net/http"

_ "github.com/lib/pq"

"yourapp/controller"
"yourapp/repository"
"yourapp/service"

)

func main() {
db, _ := sql.Open("postgres", "your_connection_string")

repo := &repository.UserRepository{DB: db}
service := &service.UserService{Repo: repo}
controller := &controller.UserController{Service: service}

http.HandleFunc("/users", controller.GetUsers)

log.Println("Server running on :8080")
http.ListenAndServe(":8080", nil)

}




---

## 🔥 What You Achieved

* Clean architecture like Laravel
* Separation of concerns
* Scalable Go backend structure

---

## 🧭 When to Use This

Use this structure when:

* Building real APIs
* Working in teams
* Scaling projects

---

## 💬 Final Thought

Go doesn’t force structure…

👉 But professionals create one.

If you combine Go performance with Laravel-style architecture, you get the best of both worlds.

---

## 🚀 Coming Next

👉 Add middleware (logging, auth)
👉 Add validation layer
👉 Dockerize Go + PostgreSQL

---

#golang #backend #architecture #programming #webdev

Structuring a Go API Like Laravel (Controller, Service, Repository)

Ahmed Raza Idrisi — Thu, 30 Apr 2026 19:21:12 +0000

If you're coming from Laravel, one thing feels missing in Go:

👉 Structure

By default, Go gives you freedom—but no clear architecture.

So in this post, we’ll structure a Go API like Laravel:

Controller → Handle request
Service → Business logic
Repository → Database

🧠 Why Structure Matters

Without structure:

Code becomes messy quickly
Hard to scale
Difficult to debug

With structure:

Clean separation of concerns
Easier testing
Production-ready codebase

📁 Folder Structure

project/
 ├── main.go
 ├── controller/
 ├── service/
 ├── repository/
 ├── model/

🧱 Model (model/user.go)

```go id="6pn1u5"
package model

type User struct {
ID int json:"id"
Name string json:"name"
}




---

## 🗄️ Repository Layer

Handles database queries



```go id="aq1u8u"
package repository

import (
    "database/sql"
    "yourapp/model"
)

type UserRepository struct {
    DB *sql.DB
}

func (r *UserRepository) GetAll() ([]model.User, error) {
    rows, err := r.DB.Query("SELECT id, name FROM users")
    if err != nil {
        return nil, err
    }
    defer rows.Close()

    var users []model.User

    for rows.Next() {
        var user model.User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    return users, nil
}

⚙️ Service Layer

Handles business logic

```go id="qf1kmz"
package service

import (
"yourapp/model"
"yourapp/repository"
)

type UserService struct {
Repo *repository.UserRepository
}

func (s *UserService) GetUsers() ([]model.User, error) {
return s.Repo.GetAll()
}




---

## 🌐 Controller Layer

Handles HTTP requests



```go id="n8t1rn"
package controller

import (
    "encoding/json"
    "net/http"
    "yourapp/service"
)

type UserController struct {
    Service *service.UserService
}

func (c *UserController) GetUsers(w http.ResponseWriter, r *http.Request) {
    users, err := c.Service.GetUsers()
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(users)
}

🚀 main.go (Wire Everything)

```go id="b4r8f2"
package main

import (
"database/sql"
"log"
"net/http"

_ "github.com/lib/pq"

"yourapp/controller"
"yourapp/repository"
"yourapp/service"

)

func main() {
db, _ := sql.Open("postgres", "your_connection_string")

repo := &repository.UserRepository{DB: db}
service := &service.UserService{Repo: repo}
controller := &controller.UserController{Service: service}

http.HandleFunc("/users", controller.GetUsers)

log.Println("Server running on :8080")
http.ListenAndServe(":8080", nil)

}




---

## 🔥 What You Achieved

* Clean architecture like Laravel
* Separation of concerns
* Scalable Go backend structure

---

## 🧭 When to Use This

Use this structure when:

* Building real APIs
* Working in teams
* Scaling projects

---

## 💬 Final Thought

Go doesn’t force structure…

👉 But professionals create one.

If you combine Go performance with Laravel-style architecture, you get the best of both worlds.

---

## 🚀 Coming Next

👉 Add middleware (logging, auth)
👉 Add validation layer
👉 Dockerize Go + PostgreSQL

---

#golang #backend #architecture #programming #webdev

🏗️ System Architecture Simplified: From Monolith to Microservices (With Real Insights)

Ahmed Raza Idrisi — Mon, 27 Apr 2026 11:18:50 +0000

When you start building applications, everything feels simple — one codebase, one database, one deployment. But as your app grows, things start breaking in subtle ways: slow performance, deployment risks, tight coupling.

That’s where System Architecture becomes critical.

Let’s break it down in a practical, developer-first way.

🔹 What is System Architecture?

System Architecture defines:

How components interact
How data flows
How scalable and maintainable your system is

Think of it as the blueprint of your application.

🔹 Monolithic Architecture (Where Most of Us Start)

In a monolith:

Everything is in one codebase
One database
Single deployment unit

✅ Pros:

Simple to build and deploy
Easy debugging (initially)
Great for MVPs

❌ Cons:

Hard to scale specific parts
Deployment becomes risky
Tight coupling across modules

Example (Laravel App):

Auth + Payments + Orders + Notifications → all inside one project

🔹 When Monolith Starts Failing

You’ll notice:

Small changes break unrelated features
Deployments take longer
Scaling requires scaling everything
Teams step on each other’s code

This is the point where you rethink architecture.

🔹 Microservices Architecture

Instead of one big app:
👉 You split into independent services

Example:

Auth Service
Payment Service
Order Service
Notification Service

Each service:

Has its own codebase
Can have its own database
Is deployed independently

🔹 Microservices Pros & Cons

✅ Pros:

Independent scaling
Faster deployments
Better fault isolation
Tech flexibility (Go, Node, PHP, etc.)

❌ Cons:

Network complexity
Debugging becomes harder
Requires DevOps maturity
Distributed data challenges

🔹 Real-World Architecture Pattern

A common modern setup:

[ Client (Vue/React) ]
          ↓
     API Gateway
          ↓
 ┌────────┼────────┐
 ↓        ↓        ↓
Auth   Orders   Payments
Svc     Svc       Svc
 ↓        ↓        ↓
 DB       DB       DB

🔹 Key Concepts You Must Know

1. API Gateway

Single entry point
Handles auth, routing, rate limiting

2. Service Communication

REST (simple)
gRPC (fast, efficient)
Message Queues (async processing)

3. Database Strategy

Shared DB ❌ (avoid)
Database per service ✅

4. Caching Layer

Redis for performance boost

5. Queue System

Background jobs (emails, reports)
Tools: Redis queues, Kafka, RabbitMQ

🔹 Monolith vs Microservices (Quick Comparison)

Feature	Monolith	Microservices
Deployment	Single	Independent
Scaling	Full app	Service-level
Complexity	Low	High
Flexibility	Low	High

🔹 What Should YOU Choose?

👉 If you're building:

MVP / Startup → Monolith
Growing SaaS → Modular Monolith
Large-scale system → Microservices

💡 Pro tip:
Don’t jump to microservices too early. Scale your architecture only when needed.

🔹 Final Thoughts

System architecture is not about trends — it’s about trade-offs.

Start simple.
Measure pain points.
Evolve your architecture.

That’s how real systems are built.

🚀 Building a CRUD API in Go with PostgreSQL (Step-by-Step)

Ahmed Raza Idrisi — Mon, 27 Apr 2026 11:09:38 +0000

In the previous post, we built a simple CRUD API in Go using in-memory storage.

Now let’s make it real-world ready by connecting it to a database:

👉 PostgreSQL

⚙️ Step 1: Install PostgreSQL Driver

We’ll use the official driver:

go get github.com/lib/pq

🧱 Step 2: Setup Database Connection

package main

import (
    "database/sql"
    "log"

    _ "github.com/lib/pq"
)

var db *sql.DB

func initDB() {
    connStr := "user=postgres password=postgres dbname=testdb sslmode=disable"

    var err error
    db, err = sql.Open("postgres", connStr)
    if err != nil {
        log.Fatal(err)
    }

    err = db.Ping()
    if err != nil {
        log.Fatal("DB not reachable:", err)
    }

    log.Println("Connected to PostgreSQL ✅")
}

🗄️ Step 3: Create Table

CREATE TABLE users (
    id SERIAL PRIMARY KEY,
    name TEXT NOT NULL
);

🧩 Step 4: Model

type User struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

➕ Create User (INSERT)

func createUser(w http.ResponseWriter, r *http.Request) {
    var user User
    json.NewDecoder(r.Body).Decode(&user)

    err := db.QueryRow(
        "INSERT INTO users(name) VALUES($1) RETURNING id",
        user.Name,
    ).Scan(&user.ID)

    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode(user)
}

📥 Get Users (SELECT)

func getUsers(w http.ResponseWriter, r *http.Request) {
    rows, err := db.Query("SELECT id, name FROM users")
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }
    defer rows.Close()

    var users []User

    for rows.Next() {
        var user User
        rows.Scan(&user.ID, &user.Name)
        users = append(users, user)
    }

    json.NewEncoder(w).Encode(users)
}

✏️ Update User

func updateUser(w http.ResponseWriter, r *http.Request) {
    idParam := r.URL.Query().Get("id")

    var user User
    json.NewDecoder(r.Body).Decode(&user)

    _, err := db.Exec(
        "UPDATE users SET name=$1 WHERE id=$2",
        user.Name, idParam,
    )

    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode("Updated")
}

❌ Delete User

func deleteUser(w http.ResponseWriter, r *http.Request) {
    idParam := r.URL.Query().Get("id")

    _, err := db.Exec("DELETE FROM users WHERE id=$1", idParam)
    if err != nil {
        http.Error(w, err.Error(), 500)
        return
    }

    json.NewEncoder(w).Encode("Deleted")
}

🌐 Step 5: Main Function

func main() {
    initDB()

    http.HandleFunc("/users", getUsers)
    http.HandleFunc("/create", createUser)
    http.HandleFunc("/update", updateUser)
    http.HandleFunc("/delete", deleteUser)

    log.Println("Server running on :8080")
    http.ListenAndServe(":8080", nil)
}

🧪 Test API

Same as before, but now data is stored in PostgreSQL 🎉

⚠️ Improvements You Should Do Next

This is still beginner-level. To make it production-ready:

Use environment variables for DB config
Add validation
Use a router (Chi / Gorilla Mux)
Structure code (controllers, services, repo)
Add connection pooling tuning

🔥 What You Learned

Connecting Go to PostgreSQL
Executing SQL queries (INSERT, SELECT, UPDATE, DELETE)
Handling real database-backed APIs

🚀 Coming Next

👉 Proper API structure in Go (like Laravel mindset)
👉 Using Docker with Go + PostgreSQL
👉 Adding authentication (JWT)

💬 Final Thought

Now you're no longer just learning Go…

👉 You're building backend systems.

🔥 Arrays vs Slices in Go (Explained in the Simplest Way)

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:10:21 +0000

If you just started learning Go, one thing will confuse you quickly:

👉 Arrays vs Slices

They look similar… but behave very differently.

Let’s break it down in the simplest way possible 👇

📦 What is an Array?

An array is a fixed-size collection.

numbers := [3]int{1, 2, 3}

Key points:

Size is fixed
Cannot grow or shrink
Rarely used in real-world Go apps

🔄 What is a Slice?

A slice is a dynamic version of an array.

numbers := []int{1, 2, 3}

Key points:

Size is dynamic
Can grow using append
Used almost everywhere in Go

⚡ Adding Data (Only Works with Slice)

numbers := []int{1, 2, 3}

numbers = append(numbers, 4)

Now:

[1, 2, 3, 4]

🧠 Under the Hood (Important Concept)

A slice is:

Pointer to an array
Length
Capacity

Think of it like:
👉 “A flexible view on top of an array”

🔍 Slice Example with Capacity

numbers := make([]int, 2, 5)

fmt.Println(len(numbers)) // 2
fmt.Println(cap(numbers)) // 5

❗ Common Mistake

arr := [3]int{1,2,3}
arr = append(arr, 4) // ❌ ERROR

Why?
👉 Because arrays are fixed size

🔥 Real-World Use Case

When building APIs:

users := []string{}

users = append(users, "Ahmed")
users = append(users, "John")

Dynamic data = slices ✅

🧭 When to Use What?

Feature	Array	Slice
Size	Fixed	Dynamic
Usage	Rare	Common
Flexibility	❌	✅

👉 In 95% of cases → use slice

💬 Final Thought

If you understand slices, you understand how Go manages data internally.

This is a foundational concept—don’t skip it.

🚀 Coming Next

Next post:
👉 Structs in Go (this is where real backend modeling starts)

golang #backend #programming #webdev #devto

🚀 Getting Started with Go (Golang) for Backend Developers

Ahmed Raza Idrisi — Wed, 22 Apr 2026 17:07:57 +0000

If you're coming from PHP, Node.js, or Laravel, learning Go can feel different—but in a good way.

Go is designed for performance, simplicity, and concurrency. Many modern systems use it for building fast APIs and scalable services.

Let’s understand it in a simple way 👇

🧠 What is Go?

Go (or Golang) is a compiled programming language created at Google.

Think of it like:

⚡ Faster than PHP/Node (compiled)
🧼 Cleaner syntax than Java
🔁 Built for concurrency (handling multiple tasks efficiently)

⚙️ Your First Go Program

package main

import "fmt"

func main() {
    fmt.Println("Hello, World!")
}

What’s happening?

package main → entry point
import "fmt" → used for printing
func main() → main function where execution starts

🔤 Variables in Go

name := "Ahmed"
age := 25

No need to write types explicitly (Go infers them).

🔁 Loops (Only ONE loop in Go)

for i := 0; i < 5; i++ {
    fmt.Println(i)
}

Simple and clean.

⚡ Functions

func add(a int, b int) int {
    return a + b
}

🧵 Concurrency (This is where Go shines)

Go uses goroutines (lightweight threads):

go func() {
    fmt.Println("Running in background")
}()

Why this matters:

Handle multiple API requests easily
Build high-performance systems
Perfect for microservices

🌐 Simple API in Go

package main

import (
    "fmt"
    "net/http"
)

func handler(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "Hello from Go API")
}

func main() {
    http.HandleFunc("/", handler)
    http.ListenAndServe(":8080", nil)
}

Run it and open:
👉 http://localhost:8080

🔥 Why You Should Learn Go

High performance (close to C++)
Simple syntax
Great for backend + APIs
Used by companies like Google, Uber, Netflix

🧭 Coming Next

In upcoming posts, I’ll cover:

Building REST APIs in Go
Connecting Go with PostgreSQL
Using Go with Docker
Concurrency deep dive (goroutines + channels)

💬 Final Thought

If you already know backend development, Go will feel like a power upgrade.

Start small. Stay consistent. Share what you learn.

golang #backend #programming #webdev #devto

DEV Community: Ahmed Raza Idrisi

# 🔬 PostgreSQL Internals: What Is Actually Inside an 8 KB Page?

🧠 First: What Is a PostgreSQL Page?

🔍 Why Does PostgreSQL Use Pages?

🧱 What's Inside a Page?

1️⃣ Page Header

2️⃣ Line Pointers

3️⃣ Free Space

4️⃣ Tuples

🧪 Let's Inspect One

Step 1: Enable pageinspect

Step 2: Create a Test Table

Step 3: Find the Table's Physical Relation

Step 4: Inspect the Page Header

🧐 What Does pagesize Tell Us?

Step 5: Inspect the Line Pointers

🔥 One Column You Should Remember: t_ctid

🧪 Let's Look at CTID From SQL

🤯 Here's Where It Gets Interesting

🧠 So What Have We Learned?

🚨 Why Should Backend Developers Care?

Why does UPDATE sometimes create table bloat?

Why does VACUUM exist?

Why can an UPDATE cause more I/O than expected?

Why do indexes matter?

Why can queries become slower as a table grows?

🧩 The Bigger Picture

🔥 Final Takeaway

🚀 What's Next?

# 🔍 What Actually Happens When PostgreSQL Executes a SELECT Query?

🧭 The High-Level Journey

1. The Client Sends SQL

2. Parser: "What Did You Write?"

3. Analyzer: "What Do These Names Mean?"

4. Rewriting

5. The Query Planner

Option 1: Sequential Scan

Option 2: Index Scan

6. EXPLAIN Lets Us See the Plan

7. The Executor Takes Over

8. But Where Is the Data?

9. PostgreSQL Works With Pages

10. Buffer Hit vs Disk Read

11. What Happens With Our Indexed Query?

12. Why Should Application Developers Care?

13. A Simple Mental Model

🔥 The Most Important Lesson

🚀 What's Next?

🚀 How I Optimize Slow MySQL Queries in Laravel: My Practical Checklist

1️⃣ Find the Slow Queries First

2️⃣ Stop Using SELECT *

3️⃣ Always Check the Execution Plan

4️⃣ Verify Your Indexes

5️⃣ Look for Composite Index Opportunities

6️⃣ Avoid Functions in the WHERE Clause

7️⃣ Watch for N+1 Queries

8️⃣ Cache Frequently Used Data

9️⃣ Add Pagination

🔟 Measure Again

My Personal Optimization Workflow

Final Thoughts

# 🎉 Happy Birthday, PHP! 🎂

Why 1 Million GoRoutines Don't Use Your GPU: Understanding CPUs, GPUs, Go's GMP Scheduler, and GPU Computing

Sections to Cover

1. Introduction

2. Understanding CPU Architecture

3. Understanding GPU Architecture

4. Go's GMP Scheduler Explained

5. What Happens When You Launch One Million Goroutines

6. Why API Calls Don't Benefit From GPUs

7. When GPUs Actually Shine

8. Go + CUDA Architecture

9. Python vs Go vs Rust for GPU Workloads

10. Real Trading System Architecture

11. Key Takeaways

Using Redis for API Caching in Go (Speed Up Your Backend)

🧠 What is Redis?

⚙️ Install Redis Package

🗄️ Example API Response

🔥 What’s Happening Here?

Step 1: Enable `pageinspect`

🧐 What Does `pagesize` Tell Us?

🔥 One Column You Should Remember: `t_ctid`

2️⃣ Stop Using `SELECT *`