I remember, I do have a recent one. An application/service was ported from PostgreSQL to MySQL but there was a particular set of queries that used to run in a 5

I remember, I do have a recent one. An application/service was ported from PostgreSQL to MySQL but there was a particular set of queries that used to run in a 5-10 minutes that wouldn't finish in 6h+. It was due for release so had a set Friday deadline giving us almost a week. The queries were large and complicated having been evolved over the course of app development specific to PostgreSQL. Also complicated by the queries being dynamically built at runtime with various in/out optional parts. If you look at the main slow core, and by comparing query plans on pg vs mysql, we could see that pg did more 'query plan normalization' (or rewriting in a way). After that we rewrote bits and bits of the query adding indexes, and partial subqueries for reuse, de-correlating subqueries, moving functions from SQL to code before/after query, force index hints, etc. By Friday we got it down to under a minute. One tip was recognizing that one of the columns in the tables was a tenant key so its cardinality was useless if already using a higher cardinality index. DBs should really have a representation for this. Writing SQL for MySQL is like writing C vs writing Prolog for PostgreSQL. Another old one was getting a large OS/2 program to run in DOS 640 KB with overlay segments that swapped out. The trick being that you want to minimize transitions between overlay segments. Parsed a call tree of the entire program and assigned overlay numbers based on some large chunks of subtrees with the most common leaf calls being in segment 99 that always lived within the 640KB. It ran fast enough and shipped without revising the shrink wrap dates.