Let’s take an example. We have two tables: users and posts. We want to find all posts made by a user with the username ‘alice’.

EXPLAIN​
SELECT p.id​
FROM posts p INNER JOIN users u ON u.id = p.user_id​
WHERE u.username = 'alice';​
                                          QUERY PLAN​
----------------------------------------------------------------------------------------------​
 Hash Join  (cost=8.17..20.21 rows=1 width=4)​
   Hash Cond: (p.user_id = u.id)​
   ->  Seq Scan on posts p  (cost=0.00..11.60 rows=160 width=8)​
   ->  Hash  (cost=8.16..8.16 rows=1 width=4)​
         ->  Index Scan using users_username_key on users u  (cost=0.14..8.16 rows=1 width=4)​
               Index Cond: ((username)::text = 'alice'::text)​

In the example above, PostgreSQL has chosen to use a Hash Join strategy. Why did it choose this strategy? How does that strategy work? Is it the best choice for this query and if not is there something I can do to help it choose a better strategy?

Let’s explore the three main join strategies PostgreSQL uses: Nested Loop Join, Hash Map Join, and Merge Join.

Nested Loop Join

The Nested Loop join is the simplest and most intuitive join strategy. It works by iterating over each row in the outer table and for each row, it looks up matching rows in the inner table. If there is an index on the join column of the inner table, it can use that index to speed up the lookups. You can think of it like a double for-loop in programming. It is a good choice when the outer table is small or very selective, and/or the inner table has a good index on the join column. In fact, it can be the very fastest strategy when the outer table is small and there is a hash index on the inner table. However, if both tables are large and there are no helpful indexes, this strategy can be very slow. Interesting side-note: This is the ‘default’ strategy when others cannot or will not be be used in PostgreSQL.

Time Complexity

• Typical: O(m * log n) (B-tree index)
• Worst case: O(m × n) (no indexes)
• Best case: O(m) (hash index)

Visualization

Performance Tips

To ensure a Nested Loop join is as efficient as possible:

• Increase selectivity on the outer table side
• Ensure inner table join column is indexed properly
• Select only columns within indexes
• Use INCLUDE in index to allow index-only scans

Hash Map Join

The Hash Map join strategy works by building a hash table in memory for one of the input tables (usually the smaller one) based on the join key. Then, it scans the other input table and for each row, it “probes” the hash table to find matching rows. This strategy is very efficient for large, unsorted tables and can handle large datasets well, as long as there is enough memory to hold the hash table. However, if the hash table is too large to fit in memory, PostgreSQL may need to write it to disk (called a ‘spill’), which can slow down performance. It is a very flexible strategy and can be thought of as a workhorse as it is often used in practice.

The Hash Map join requires an equality condition (e.g., ON a.id = b.a_id) and is not suitable for non-equality joins.

Time Complexity

• Best case: O(m + n)
• Worst case: O(m × n) (when many hash collisions occur and/or when ‘spilling’ to disk because there is not enough work_mem to hold the hash table)

Visualization

Performance Tips

To ensure a Hash Map join is as efficient as possible:

• Reduce row width (select fewer columns) to prevent disk ‘spills’
• Filter more data early to reduce burden of hashing step
  • Expand WHERE clause
  • Add another join condition
  • Use a sub-query or CTE (Common Table Expression)

Merge Join

The Merge Join strategy works by first sorting both input tables on the join key, and then merging them together in a single pass. This strategy is very efficient when both input tables are already sorted on the join key, or when sorting is needed for other reasons (e.g., an ORDER BY clause). B-tree indexes are inherently sorted and can be leveraged to avoid the sorting step. However, if the input tables are large and unsorted, the sorting step can be expensive and may make this strategy less efficient than others. It is often the preferred strategy when conditions are right.

Time Complexity

• Best case: O(m + n) (if both inputs are already sorted or sorted B-tree indexes can be used)
• Worst case: O(m log m + n log n) (both inputs need to be sorted first)

Visualization

Performance Tips

To ensure a Merge Join is as efficient as possible:

• Prefer B-tree indexes (vs. hash index) to ensure they are sorted
• Reduce row width (select fewer columns)
• Select only columns within indexes
• Match collation & data types on both sides to keep scans orderable
• Use multi-column indexes in same order as join conditions

General Tips

Postgres choses a join strategy based on various factors including table sizes, available indexes, data distribution, query structure, and more. To ensure you are giving Postgres the best chance to choose the most efficient join strategy, consider the following general tips.

Ensure table statistics are accurate

Make sure your table statistics are up-to-date so the query planner can make informed decisions about join strategies. You can manually run ANALYZE on your tables and/or ensure autovacuum is running properly to keep statistics current. Statistics play a big role in the query planner’s decision on join strategy!

Index available on join column(s)

This one is probably obvious but it is worth mentioning. Having an index on the join column(s) can significantly speed up join operations, especially on the “inner input” side when Nested Loop join is being used.

Strive for simple equality join conditions

If possible, use simple equality conditions in your join clauses (ON a.id = b.a_id) and avoid operations such as <, <=, >, >=, !=, LIKE . Complex expressions or functions can prevent the use of the Hash Map join strategy where it might otherwise be the best choice.

Avoid functions/casts on join conditions

Using functions or type casts on join conditions can prevent the use of indexes and lead to less efficient join strategies. If you must use a function or cast, consider creating a generated column that pre-computes the value and indexing that column.

Use multi-column indexes in same order as join conditions

If your join condition involves multiple columns, consider creating a multi-column index that matches the order of the columns in the join condition. This can help the query planner choose a more efficient join strategy.

Be careful with SELECT columns

Selecting only the columns you need and/or are included in indexes can impact performance more than you might expect. This is especially true when using the Hash Map join strategy where reducing row width can help prevent ‘spilling’ to disk. Also, if you select only columns that are included in an index, Postgres can use an index-only scan which can be significantly faster than a regular scan.

Perturbing the Join Strategy

If your query is still slow even after ensuring you are giving Postgres everything possible to chose the most efficient join strategy, you can perturb the join strategy by disabling certain strategies (for the current session) using the following commands:

SET enable_hashjoin = off;​
SET enable_mergejoin = off;​
SET enable_nestloop = off;

By inspecting the EXPLAIN output after disabling specific strategies, you can see how the query planner’s choice changes and what factors are impacting its decision to choose a particular join strategy. This can help you identify potential optimizations for your query.

Here’s how to do it!

1. First of all, you’ll need to create a Bluesky app password to use. Go to https://bsky.app/settings/app-passwords and generate a password for use later in these steps.
2. Create a new Zap: Go to your Zapier dashboard, select “Zaps” in sidebar, and then click “+ Create > New Zap”.
3. Choose a Trigger: Select the app and event that will trigger the Zap in the first step of the Zap. For example, you can use “RSS by Zapier” to post new items from an RSS feed. Edit the details for this trigger per your specific needs.
4. Choose an Action: In the second step, click “Action” and select “Code” (Code by Zapier). Then, do the following steps:

   1. Choose “Run JavaScript” as the action event then click “Continue”.

   2. Add 3 items for “Input Data” and provide the values.

      • username: Your Bluesky username (without the @ symbol; for example “bradymholt.bsky.social” ).
      • password: Your Bluesky password.
      • post_text: The text you want to post to Bluesky. You’ll likely want to use a variable from the trigger step here.

   3. Paste in the following code:

      const sessionResponse = await fetch("https://bsky.social/xrpc/com.atproto.server.createSession", {​
          method: 'POST',​
          body: JSON.stringify({​
              identifier: inputData['username'], password: inputData['password']​
          }),​
          headers: {​
              'Content-Type': 'application/json'​
          },​
          redirect: 'manual'​
      });​
      ​
      // Check if the response status is OK​
      if (!sessionResponse.ok) {​
          console.error('Failed request', await sessionResponse.text());​
          return null;​
      }​
      ​
      const responseBody = await sessionResponse.json();​
      ​
      if (!responseBody.accessJwt) {​
          console.error('accessJwt not found in the response');​
          return null;​
      }​
      ​
      const postText = inputData['post_text']};​
      ​
      const recordData = {​
          "$type": "app.bsky.feed.post",​
          "text": postText,​
          "createdAt": new Date().toISOString()​
      };​
      ​
      const postData = {​
          repo: inputData['username'],​
          collection: 'app.bsky.feed.post',​
          record: recordData​
      };​
      ​
      const postResponse = await fetch("https://bsky.social/xrpc/com.atproto.repo.createRecord", {​
          method: 'POST',​
          body: JSON.stringify(postData),​
          headers: {​
              'Content-Type': 'application/json',​
              'Authorization': `Bearer ${responseBody.accessJwt}`​
          }​
      });​
      ​
      if (!postResponse.ok) {​
          console.error('Failed request', await postResponse.text());​
          output = {​
              success: false,​
              message: "Failed to create record"​
          };​
          return;​
      }​
      ​
      const postResponseBody = await postResponse.json();​
      if (!postResponseBody.success) {​
          console.error('Failed to create record', postResponseBody.message);​
          output = {​
              success: false,​
              message: postResponseBody.message​
          };​
          return;​
      }​
      ​
      output = {​
          success: true​
      };

5. Click “Continue” to test the action and complete the setup.

That’s it! Enjoy.

Instructions

First off, you’ll want to follow the Get Started with Drizzle and SQLite docs to get a local SQLite database setup and working within SvelteKit. This will involve installing some npm packages and creating a few files including the drizzle.config.ts file and the schema.ts file. Be sure to run npx drizzle-kit generate && npx drizzle-kit migrate to create and run the initial migration file from ./drizzle folder. The guide SvelteKit with SQLite and Drizzle might be helpful here.

Before proceeding with the instructions below, your app should be setup to work with a local SQLite database using Drizzle.

Now, you’ll want to get your app configured to work with Cloudflare Pages. Follow the SvelteKit Cloudflare Pages instructions. You will basically install a npm package and and modify the svelte.config.js file.

svelte.config.js changes

I did find that the instructions for svelte.config.js needed to be changed slightly. platformProxy.persist needs to be set to true in order to persist the local SQLite database. Also, change configPath to "wrangler.json" (from "wrangler.toml").

platformProxy: {​
  // Other config ...​
  configPath: "wrangler.json";​
  persist: true;​
}

Install and configure wrangler

Install the wrangler CLI tool with npm install wrangler --save-dev.

Then, create a wrangler.json file with the following contents in the root of your project.

{​
  "$schema": "node_modules/wrangler/config-schema.json",​
  "name": "my_project_name",​
  "compatibility_date": "2025-02-04",​
  "pages_build_output_dir": ".svelte-kit/cloudflare",​
  "d1_databases": [​
    {​
      "migrations_dir": "./drizzle",​
      "binding": "DB",​
      "database_name": "my-d1-database-name",​
      "database_id": "database_id_TBD"​
    }​
  ]​
}

Create remote D1 database

Now, you’ll create your D1 database on Cloudflare using the wrangler CLI.

Run the following:

npx wrangler d1 create my-d1-database-name

The output of this command will provide you with JSON config for the wrangler.json file. Just copy paste the value of database_id and update your wrangler.json file, replacing the "database_id_TBD" value.

Create local “D1” (SQLite) database

To create a local SQLite database used for development, you will first need to find the name of the initial Drizzle migration file. This file should be named in format 0000_[migration_file].sql and be located in the ./drizzle directory.

Now, run the following command, specifying the specific migration file you located.

npx wrangler d1 execute my-d1-database-name --local --file=./drizzle/0000_[migration_file].sql

A .sqlite file will be created in .wrangler/state/v3/d1/miniflare-D1DatabaseObject/. You should find this file and note its name.

drizzle.config.ts

The drizzle.config.ts file is used by Drizzle when working with migrations. You need to change the dbCredentials.url to the location of the SQLite database created by wrangler in the previous step.

Your drizzle.config.ts file will look something like this:

import { defineConfig } from "drizzle-kit";​
​
export default defineConfig({​
  schema: "./src/lib/server/schema",​
  dialect: "sqlite",​
  out: "./drizzle",​
  dbCredentials: {​
    url: ".wrangler/state/v3/d1/miniflare-D1DatabaseObject/e7352547963de7050bd7d94658afc4fe78b61811b7815da12d90be8e863abf4d.sqlite",​
  },​
});

SvelteKit modifications

Update your app.d.ts file to include the env: Env field. Cloudflare (and wrangler locally) will inject the DB variable binding into the env object which will be used to connect to D1.

declare global {​
    namespace App {​
        interface Platform {​
            env: Env;​
        }​
    }​
}​
​
export {};

Now, anywhere you want to interact with D1 in your SvelteKit code, you’ll want to import { drizzle } from 'drizzle-orm/d1'; and instantiate a db object by passing in the DB binding like this: const db = drizzle(platform.env.DB);.

Here is an example of how you would set things up and select from a users table:

import { drizzle } from 'drizzle-orm/d1';​
​
export const actions = {​
  fetchUsers: async ({ request, platform }) => {​
    const db = drizzle(platform.env.DB);​
    const users = await db.select().from("users");​
    ...​
  }​
} satisfies Actions;​

package.json

Finally, add the following scripts to package.json to make it easier to work with the database and deploy the site.

• db:migrate:local - Migrate the local SQLite database
• db:migrate:prod - Migrate the Cloudflare D1 database
• deploy - Build the site, migrate the production Cloudflare D1 database, and deploy the site

{​
  "scripts": {​
    ...​
    "db:migrate:local": "drizzle-kit migrate",​
    "db:migrate:prod": "wrangler d1 migrations apply DB --remote",​
    "deploy": "npm run build && npm run db:migrate:prod && wrangler pages deploy"​
  }​
}

Note: for db:migrate:prod, we call wrangler d1 migrations apply which uses the wrangler CLI (rather than drizzle-kit!) to apply the migrations to D1. wrangler is able to read and work with the migrations created by Drizzle. I found ways for drizzle-kit to do this directly, but it was more complicated and I found this to be the easiest way to do it.

Starting up local development

Run npm run db:migrate:local to run any pending migrations you may have for the local database. Then run npm run dev to start up the local development server. All interactions with Drizzle should now be targeting the local SQLite database, using the DB binding.

Deploying to Cloudflare

Run npm run deploy to build the site, run any pending migrations on Cloudflare D1, and deploy the site to Cloudflare.

• It can take a very long time to complete
• It can lock rows for the duration of the delete leading to blocked queries
• It can cause the the transaction log to become huge because the delete transaction is so large

To work around these issues, you can delete rows in batches. There are various ways to do this but I prefer the following approach, using a DELETE ... WHERE ... IN (SELECT ... LIMIT) query with a \watch command in psql.

First, construct a delete query using a WHERE .. IN statement and a LIMIT to ensure only a batch of records are deleted. Here’s an example that deletes 1,000 rows from a table named my_table where the created_at column is older than 30 days:

DELETE FROM my_table​
WHERE id IN (​
  SELECT id​
  FROM my_table​
  WHERE created_at < now() - interval '30 days'​
  -- Delete only 1000 rows at a time​
  LIMIT 1000​
);

Execute this query within psql and ensure it completes without error.

Now, run \watch 1 within psql. This will re-run the last query every second and display the number of rows deleted.

After a few seconds, you should see output like this:

DELETE 1000​
DELETE 1000​
DELETE 1000

This indicates that 1,000 rows are being deleted every second.

When all rows have been deleted, you will see output like this:

DELETE 0​
DELETE 0​
DELETE 0

Since all rows have been deleted at this point, you can stop the watch command with CTRL+C in psql.

If extensions are recommended, VS Code users should see the following popup when opening the workspace folder:

There is a problem though: if a user dismisses this popup, it will not be shown again for the workspace. Also, if they have extensions.ignoreRecommendations set to true, they will never see this popup in the first place.

I found a way to install them automatically when opening a workspace folder in VS Code. With a "runOn": "folderOpen" VS Code task, we can run some code when the workspace is opened. Using a shell script, we can parse the extensions.json file and then run code --install-extension for each extension to install it.

In .vscode/tasks.json, you can create the install tasks like this:

{​
  "version": "2.0.0",​
  "tasks": [​
    {​
      "label": "Install All Recommended Extensions",​
      "type": "shell",​
      "windows": {​
        "command": "echo 'Not Supported on Windows'"​
      },​
      "command": "node -e \"console.log(JSON.parse(require('fs').readFileSync('./.vscode/extensions.json')).recommendations.join('\\n'))\" | xargs -L 1 code --install-extension",​
      "runOptions": {​
        "runOn": "folderOpen"​
      },​
      "presentation": {​
        "reveal": "silent"​
      }​
    }​
  ]​
}

Note: The task assumes node (Node.js) and code CLI commands are available. Instructions for installing the VS Code CLI code can be found here.

With that task in place, extensions will be installed automatically! It looks like this when you open the workspace folder in VS Code:

How do you even describe or define “burnout”, anyway? For me, it’s when I feel like I simply cannot go on. I am exhausted and either depressed or seemingly on the verge of depression.

According to WebMD:

Burnout is a form of exhaustion caused by constantly feeling swamped. It’s a result of excessive and prolonged emotional, physical, and mental stress. In many cases, burnout is related to one’s job.

There are times when I am simply unmotivated or feeling a bit passionless about my work but this doesn’t mean I am burned out. Burnout is more of an intense feeling of exhaustion and it usually follows a very intense period of work; at least this is what I have experienced.

Here are four things I have learned about dealing with burnout:

1. Don’t panic

It’s temping to freak out when I start to get burned out. “What does this mean?” “I can’t go on…what am I going to do?” The thing is, burnout passes so if you’re patient you’ll get through it.

2. Make a change

Although my situation has many times been out my control I still have the control over other areas of my time and am able to make one or more changes. Simply making a change in my daily routines and habits has helped me. In the past I’ve implemented changes like exercising more, picking up a new hobby, avoiding television, taking a few days off and going on a trip. Yes, sometimes changing jobs is the right change to make, especially if you are in an environment that is perpetually exhausting and demanding.

3. Do something you enjoy

Making a change is good but doing something I really enjoy is important. For me, it means picking up the guitar, going on nature walks, or spending more time with my family.

4. Be around people

Forcing myself to be around people more has helped me in the past. This one is not intuitive to me because my inclination is to isolate when I’m exhausted. But, rubbing shoulders and socializing is helpful for me.

As a bit of an aside, my tell-tale sign that I am burned out is when I have a desire to quit my job and take up a manual labor job such as delivering packages or working in a warehouse. There is nothing wrong with those respectable jobs, of course. I don’t understand the psychology behind it but it’s my own indicator I need to act.

The library package is named syndication-fetcher. The repository is located here: https://github.com/bradymholt/syndication-fetcher and it can be installed with npm install syndication-fetcher.

Usage example

import { fetchFeed } from "syndication-fetcher";​
const feed = await fetchFeed("https://www.geekytidbits.com/rss.xml");​
​
/* `feed` object looks like this:​
{​
  title: string;​
  description: string;​
  link: string;​
  items: [​
    {​
      id: string;​
      title: string;​
      description: string;​
      link: string;​
      pubDate: Date | null;​
      content: string;​
    }​
  ]​
}​
*/

Since it just hit v1.0 I thought now would be a good time to play with it. I’ve also been learning more about Cloudflare Workers, Pages, KV, etc. and decided I would like to build a simple web app using SvelteKit and deploy it to Cloudflare Pages.

The result of my playing is simple app template that implements user authentication. You can register a new user, login with a new registration, initiate a Forgot Password flow including sending a reset email. You can see the GitHub repo here: https://github.com/bradymholt/sveltekit-auth-template and the live site here: https://sveltekit-auth-template.pages.dev/.

Things I learned and worked with while building this template:

• How to create JWTs on Cloudflare Workers
• How to use KV, Cloudflare’s key value store
• Sending emails with MailChannels
• Validation with zod
• TailwindCSS - although I initially used Tailwind I changed my mind and removed it. But, I took it for a spin and learned a bit about it.
• Self-hosting web fonts
• PostCSS - I haven’t done much with PostCSS before but I was able to play with it and in particular, use the “postcss-nested” plugin to get nested CSS working without having to use Sass or Less.

What I ended up building is silly and trivial but it was fun: Daily WTF JavaScript - a site that displays a daily rotating snippet of JavaScript that makes you say “WTF!”. Yes, there are no shortage of examples.

As always when building things, I learned plenty:

• Vite - I used Vite as a build tool and wow was I impressed. This felt so much better than using webpack or one of its derivatives.
• place-items: center; for centering an HTML element horizontally and vertically
• GitHub Actions with GitHub Pages - My workflow to publish the site to GitHub Pages uses GitHub Actions, which is the new generation method for working with pages. I can now use this template as a baseline for other projects.
• Although I’ve used jsdom before, it’s been awhile and I was able to reintroduce myself to its usefulness to parse HTML on the server side.
• I was exposed to the wonderful world of CSS Gradient Swatches.
• I learned more about PostCSS and want to continue learning and using it further.

So why did I switch? It came down to 3 reasons:

1. The size. I like the smaller size and I can’t find a new, flagship Android phone in this size.
2. The app quality. I like the Android operating system and think Google has really refined it. But, the quality of the Google Play store apps are, in general, not as good as their iPhone counterparts. It’s sad but I think it’s undeniably true.
3. I wanted to try something new. ¯\_(ツ)_/¯

Things I Like

• Using the Google ecosystem (apps, services) on the iPhone is very feasible. One of my biggest hesitations in switching to iOS was the ease of continuing use of the Google ecosystem and I was not disappointed. The only annoyance I’ve found in this area is that iOS defaults opening address and web links in Apple Maps and Safari. But, it’s not as obtrusive as I expected.
• The quality of the apps. This was one of the reasons I switched and after using a few of my favorite apps I see a noticeable quality difference. It’s obvious many companies prioritize the quality of their iOS apps. Some examples: 1Password, Tablo TV, Zillow. In particular, the experience using 1Password on iOS is significantly better (reliable and seamless autofill, Face ID speed) than Android and since I use it so often this is no small factor.
• The Shortcuts app - I’m a sucker for automation and Shortcuts is a powerful, simple, and fun app.
• Widgets - I always enjoyed Android home screen widgets but in recent years it appears they have fallen out of interest of app developers. iOS has widgets and they are very polished and useful. The Weather and Google Calendar widgets are two of my favorites (so far…).
• The ability to enable “Do Not Disturb” mode “Until I Leave” a location.
• macOS interoperability:
  • Universal Clipboard - I love being able to copy text on my MacBook and paste it on my iPhone (and vise-versa)! This is very useful.
  • Calls and Messages - it is very convenient to be able to make / receive phone calls and send / receive messages on my Mac without having to pick up my phone, while sitting at my desk. Granted, Google has “Messages for Web” that allows you to send / receive messages from a web app but this is only for messages and its pairing mechanism is finicky sometimes.

Things I Don’t Like

• Voice Dictation - Voice Dictation on iOS is not up to par with Android. Android’s voice dictation is much faster and more accurate. I have come to rely upon it heavily, especially for texting.
• Google Chrome interface - I don’t like the interface Chrome has on iOS. Undoubtedly, Google is trying to make its interface more iOS-like, but I prefer the layout on Android with tabs and navigation buttons on the top.
• Physical button location - Maybe it’s because I’m left handed but I very much prefer to have the power button on the left side of the phone and the volume buttons on the right side and on the iPhone 13, it is exactly the opposite of this.
• Lightening adapter - Ugh, need I say more? I had to buy a bunch of adapters which was not fun.
• The inability to schedule text messages - I love this feature on Android and it simply doesn’t exist on iOS.

With all things considered, I am very happy and glad I made the switch!