gh-select 2.5.0 has just been released

29:I["bf8de5d20428",[],"TableOfContents",1] 2a:I["24f96c4095d3",[],"BlogPostClient",1] 2c:I["4969c3a730f2",[],"ReactionBar",1] 2d:I["3e3ac6ca1452",[],"CommentSection",1] 2e:I["24f96c4095d3",[],"PostNavigation",1] 2f:Tf6d,I had one of those moments where an AI assistant gave technically plausible database advice, but some of it was too generic to trust directly. The schema in question was a WhatsApp history app. The `messages` table had around 932k rows, and the assistant suggested a mix of things: partition the table, normalize a few small lookup values, remove denormalized `last_message` fields, add indexes, maybe add caching. Some of that sounded reasonable at first glance. Most of it was not the first move. ## The Actual Problem The slow path was not the shape of the whole schema. It was substring search over message text. The app has queries like this: ```sql SELECT id, chat_id, message, timestamp FROM public.messages WHERE message ILIKE '%photo%' ORDER BY timestamp DESC LIMIT 50; ``` Without the right index, Postgres has no cheap way to answer `ILIKE '%term%'`. A normal btree index is not useful for that pattern because the wildcard is at the start of the string. So the baseline query plan looked like this: ```text Parallel Seq Scan on messages Execution Time: 313.753 ms ``` For another term it was worse: ```text Parallel Seq Scan on messages Execution Time: 827.190 ms ``` That is exactly the kind of thing that feels fine during development and then gets annoying once the dataset becomes real. ## The Fix Postgres has a good tool for this: `pg_trgm`. I added trigram indexes for the columns used by fuzzy and substring search: ```sql CREATE EXTENSION IF NOT EXISTS pg_trgm; CREATE INDEX IF NOT EXISTS idx_messages_message_trgm ON public.messages USING gin (message gin_trgm_ops); CREATE INDEX IF NOT EXISTS idx_chats_name_trgm ON public.chats USING gin (name gin_trgm_ops); ANALYZE public.messages; ANALYZE public.chats; ``` The important part is not just creating indexes. The important part is measuring before and after with the same query shape. ## The Result | Term | Before | After | Change | | -------- | -----------: | ----------: | ----------: | | `http` | `827.190 ms` | `21.621 ms` | ~38x faster | | `photo` | `313.753 ms` | `4.566 ms` | ~69x faster | | `thanks` | `327.628 ms` | `4.210 ms` | ~78x faster | | `test` | `323.533 ms` | `5.479 ms` | ~59x faster | The post-index plan changed to this: ```text Bitmap Index Scan on idx_messages_message_trgm Bitmap Heap Scan on messages Execution Time: 4.566 ms ``` That is the difference I wanted to see. Not just a new index existing in `pg_indexes`, but the planner actually choosing it. ## Why I Did Not Partition the Table The assistant also suggested partitioning `messages` by date or chat ID. That is not wrong in every context, but it is the wrong first move here. Around one million rows is not scary for Postgres. Partitioning adds operational complexity: import paths, constraints, query planning behavior, migrations, and future maintenance all get more complicated. If the slow query is a text search that cannot use an index, partitioning is mostly avoiding the real issue. The better order is: 1. Measure the real query. 2. Check the plan. 3. Add the smallest index that matches the access pattern. 4. Re-run the same benchmark. 5. Only reach for heavier schema changes if the measured result is still not good enough. ## The Takeaway Generic schema advice is cheap. Query plans are evidence. In this case the fix was not a rewrite, a cache, a message queue, or table partitioning. It was one missing trigram index on the column people actually search. The part worth keeping is the workflow: ```sql EXPLAIN (ANALYZE, BUFFERS) SELECT id, chat_id, message, timestamp FROM public.messages WHERE message ILIKE '%photo%' ORDER BY timestamp DESC LIMIT 50; ``` Run that before. Run it after. Store the result. If the plan changes from `Seq Scan` to `Bitmap Index Scan`, and the execution time drops from hundreds of milliseconds to single digits, you have a real performance fix instead of a theoretical one.30:T18b8,Lately I have been trying to ship smaller things more often instead of waiting until a project feels "finished." This post is a simple running note: what went out, what changed behind the scenes, what is still rough, and what I want to improve next. It is less of a polished launch post and more of a snapshot. A place to document momentum while the work is still fresh. ## What shipped - **[ @remcostoeten/analytics ]** There was no real reason for this, besides me wanting to roll my own service and learn some more back-end. It's a privacy-first, event-sourced analytics engine built on **Bun**, **Hono** (Vercel Edge), and **Neon/Postgres**. It leverages JSONB for a schema-less event stream that supports advanced forensics (Browser/OS parsing) out of the box. - **Possibilities**: Track Web Vitals (LCP, CLS, INP), E-commerce revenue, A/B test variants, and full user funnels without migrations. - **Usage**: ```tsx import { Analytics, trackEvent, useAnalytics } from '@remcostoeten/analytics' // 1. Initialize globally with robust user segmentation export default function RootLayout({ children }) { return ( {children} ) } // 2. Rich e-commerce tracking integrated into feature components function CheckoutButton({ cart }) { const { identify, track } = useAnalytics() const handleCheckout = () => { // Tie subsequent events to a specific user identity securely identify('USR_8921', { trait: 'premium_tier', LTV: 450 }) // Fire a complex schema-less event with full type-safety payload track('checkout_initiated', { cartValue: cart.total, currency: 'EUR', items: cart.items.map(i => i.sku), appliedDiscount: 'SUMMER_SALES_26', abTestVariant: 'checkout_v2_red_btn' }) } return } ``` - **GitHub**: [remcostoeten/analytics](https://github.com/remcostoeten/analytics) - **Live Demo**: [analytics.remcostoeten.nl](https://analytics.remcostoeten.nl) - **[ @remcostoeten/use-shortcut ]** I built this because existing shortcut libraries felt clunky. I wanted a "human-readable" API that felt like writing a sentence, with perfect TypeScript autocompletion for every key and modifier. - **Tech Talk**: A zero-dependency React hook built with a fluent/chainable builder pattern. It handles event listener cleanup automatically and supports advanced modifier combinations without manual string parsing. - **Possibilities**: Support for command combos (Ctrl/Cmd + K), sequential key presses (G then H), global/scoped listeners, and automatic documentation generation via description tags. - **Usage**: ```tsx import { useShortcut, ScopeProvider } from '@remcostoeten/use-shortcut' function AdvancedCommandPalette() { const searchRef = useRef(null) // Builder pattern enables complex sequencing and scope locking useShortcut() .sequence('g', 't') // Wait for 'g' THEN 't' (Go To) .or() .cmd() .shift() .key('p') // Or use standard modifier combo .scope(searchRef) // Only trigger if this element doesn't have focus .preventDefault() .debounce(150) // Prevent rapid firing bounds .action((event, meta) => { console.log(`Triggered via: ${meta.triggerType}`) searchRef.current?.focus() }) .description('Navigate to specific project view') .build() return } ``` - **GitHub**: [remcostoeten/use-shortcut](https://github.com/remcostoeten/use-shortcut) - **Live Demo**: [use-shortcut.vercel.app](https://use-shortcut.vercel.app) - **[ oauth-app-automator ]** I hate creating OAuth applications when using social providers. Thus I automated the process with a Python program. Authenticate once and from there you're able to create, (bulk) delete apps and test credentials. Write secret and client ID to clipboard, or straight in your environment variable. - **Tech Talk**: Python-based automation that scripts the actual browser interactions (via Selenium/Playwright) to fetch credentials directly from provider portals (GitHub/Google). - **Possibilities**: Bulk creation of developer apps, automatic `.env` file updates, and a clean interactive CLI/TUI for managing credentials. - **GitHub**: [remcostoeten/oauth-app-automator](https://github.com/remcostoeten/oauth-app-automator) - **[ Kuizer ]** Maintaining large TypeScript projects often leads to "dead code rot." I needed a fast, reliable way to prune the tree without manual auditing—so I built Kuizer to handle the heavy lifting. - **Tech Talk**: A high-performance CLI built with **Bun**. It analyzes the TypeScript import graph to detect unreachable files and unused exports by deep-diving into the AST. - **Possibilities**: Browse findings in an interactive terminal UI (TUI), categorize unused exports (types vs components), and safe snapshot-based rollbacks for every automated fix. - **Usage**: ```bash # Run a deep AST dependency graph analysis to find dead code # -i: Interactive TUI mode for reviewing findings # --fix: Automatically treeshake and safely remove unused code # --snapshot: Create a rollback snapshot before mutating files # --exclude: Glob array pattern for files to ignore during analysis kuizer analyze \ --interactive \ --fix \ --snapshot ./.kuizer-backups/ \ --exclude "**/*.test.ts" "src/legacy-api/**" \ --threshold "medium" ``` - **GitHub**: [remcostoeten/kuizer](https://github.com/remcostoeten/kuizer)28:[[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"BlogPosting\",\"headline\":\"gh-select 2.5.0 has just been released\",\"description\":\"gh-select 2.5.0 is out. Smarter search, rate limits, clones found anywhere, a redesign and new themes.\",\"image\":\"https://www.remcostoeten.nl/og?title=gh-select%202.5.0%20has%20just%20been%20released\",\"author\":{\"@type\":\"Person\",\"@id\":\"https://www.remcostoeten.nl/#person\",\"name\":\"Remco Stoeten\",\"url\":\"https://www.remcostoeten.nl\"},\"publisher\":{\"@type\":\"Person\",\"@id\":\"https://www.remcostoeten.nl/#person\",\"name\":\"Remco Stoeten\",\"logo\":{\"@type\":\"ImageObject\",\"url\":\"https://www.remcostoeten.nl/favicon.svg\"}},\"datePublished\":\"10-03-2026\",\"dateModified\":\"10-03-2026\",\"mainEntityOfPage\":{\"@type\":\"WebPage\",\"@id\":\"https://www.remcostoeten.nl/blog/gh-select\"},\"keywords\":[\"frontend development\",\"React\",\"TypeScript\",\"Next.js\",\"Personal\",\"CLI\",\"Go\",\"Open Source\"]}"}}],["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"BreadcrumbList\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https://www.remcostoeten.nl/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Blog\",\"item\":\"https://www.remcostoeten.nl/blog\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"gh-select 2.5.0 has just been released\",\"item\":\"https://www.remcostoeten.nl/blog/gh-select\"}]}"}}]],["$","$L29",null,{}],["$","section",null,{"className":"px-1 sm:px-2","children":[["$","$L2a",null,{"publishedAt":"10-03-2026","topic":"Personal","tags":["Personal","CLI","Go","Open Source"],"title":"gh-select 2.5.0 has just been released","summary":"gh-select 2.5.0 is out. Smarter search, rate limits, clones found anywhere, a redesign and new themes.","readTime":"3 min","slug":"gh-select","uniqueViews":3,"totalViews":33}],["$","hr",null,{"className":"my-10 border-border/60"}],["$","article",null,{"className":"prose prose-quoteless prose-neutral dark:prose-invert max-w-none prose-headings:scroll-mt-24 prose-a:text-foreground prose-a:underline prose-a:decoration-border prose-a:underline-offset-4 hover:prose-a:decoration-foreground prose-img:rounded-md prose-code:before:content-none prose-code:after:content-none","children":"$L2b"}],["$","$L2c",null,{"slug":"gh-select"}],["$","$L2d",null,{"slug":"gh-select"}],["$","$L2e",null,{"prevPost":{"slug":"measuring-postgres-search-indexes-before-and-after","content":"$2f","metadata":{"title":"Measuring Postgres Search Indexes Before and After","publishedAt":"2026-06-06","summary":"A small real-world benchmark from a WhatsApp history app: adding trigram indexes turned broad message searches from parallel sequential scans into bitmap index scans, cutting queries from hundreds of milliseconds to single digits.","tags":["PostgreSQL","Performance","Indexes","Engineering"],"draft":false,"slug":"measuring-postgres-search-indexes-before-and-after","updatedAt":"2026-06-06","author":"Remco Stoeten","topic":"Engineering","readTime":"4 min"},"views":19,"uniqueViews":17},"nextPost":{"slug":"what-ive-been-shipping-lately","content":"$30","metadata":{"title":"What I've been shipping lately","publishedAt":"10-16-2026","summary":"A lightweight running log of what I have been building, what shipped, what changed, and what I am paying attention to next.","tags":["Personal","Build Log","Shipping"],"topic":"Personal","draft":false,"slug":"what-ive-been-shipping-lately","updatedAt":"10-16-2026","author":"Remco Stoeten","readTime":"4 min"},"views":47,"uniqueViews":32},"basePath":"/blog"}]]}]] 31:Tc6c,gh-select 2.5.0 has just been released | Remco Stoeten1:[["$","div",null,{"hidden":true,"suppressHydrationWarning":true,"dangerouslySetInnerHTML":{"__html":"$31"}}],"$L32"] 2:null 33:"StreamedIconsInsertion" 34:I["b6b9a8892e1e",[],"$33",1] 32:["$","$L34",null,{"metadataKey":"vi78cd1fccc44f8c5a"}] 2b:E{"digest":"1817928274"}