A self-join is a normal join where a table is compared against itself. It looks scary until you give the two copies different names, then it's just a join like any other.
An index isn't free. It speeds up the reads that use it and slows down every single write to that table. Knowing which columns are worth it is the actual skill.
Both let you use the result of one query inside another. A CTE just gives that inner query a name up front, so the whole thing reads top to bottom instead of inside-out.
Every window function looks at a 'frame', a slice of nearby rows. ROWS counts physical rows; RANGE counts by value. They usually agree, until there are duplicate values.
10-minute delivery isn't just fast e-commerce. It's a different business with its own metrics: SLA breach rate, dark-store utilization, and delivery cost per order.
A North Star metric is the single number a company trusts most to mean 'the product is genuinely getting better.' Most teams accidentally pick the wrong one.
Partitioning doesn't shrink a table. It splits it into pieces so a well-aimed query only has to open the piece it needs.
A p-value is not 'the chance your result is a fluke.' It's a narrower, stranger question, and misreading it is the single most common statistics mistake in the industry.
One overall conversion rate tells you something's wrong. Breaking it into step-by-step numbers tells you what, and that's the entire skill.
Your SQL never says HOW to do a join. The planner picks from three strategies based on table size and indexes. Knowing them tells you what a slow join is actually doing.
A resume isn't read carefully at first, it's scanned fast. Knowing what a recruiter's eye actually catches in those first few seconds changes how you should write every line.
A regular view re-runs its query every time you read it. A materialised view runs it once and remembers the answer, until you tell it to refresh.
The database quietly reorders your query so filters happen as early as possible, before an expensive join, not after. Knowing when it CAN'T do that is what matters.
Open-ended product questions don't reward improvisation. A simple, repeatable structure, walked through out loud, outperforms a great idea with no visible process.
EXPLAIN looks like noise at first. Once you know three things to look for, it tells you exactly why a query is slow.
A pivot turns a long list of transactions into a spreadsheet-style grid. Unpivot does the reverse. Neither is a keyword in Postgres, both are patterns you build by hand.
A change can look like a huge win in week one and fade by week three, or start weak and grow stronger. Both are predictable, named patterns, not random noise.
Comparing a row to its neighbor used to mean joining a table to itself. LAG and LEAD let a row see the previous or next row directly, in one line.
NULL isn't zero and isn't an empty string, it means 'unknown.' And comparing anything to 'unknown' gives you 'unknown,' which quietly drops rows you expected to keep.
One retention number tells you almost nothing. Grouping users by when they joined, and tracking each group over time, is the closest thing analytics has to a truth serum.