https://nalar.dev/tags/joins/ Recent content in Joins on Nalar Hugo en-us Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/postgresql-join-collapse-bounds-planner-search/ Tue, 15 Sep 2026 00:00:00 +0700 https://nalar.dev/postgresql-join-collapse-bounds-planner-search/ <p>PostgreSQL can reorder many joins instead of treating SQL text order as a fixed execution sequence. That freedom gives the planner more candidate plans, but the search space grows rapidly as a query brings more relations into one join problem. Two planner settings, <code>join_collapse_limit</code> and <code>from_collapse_limit</code>, place boundaries on how aggressively PostgreSQL flattens query structure before it searches for a plan.</p> <p>These limits are not execution-time row caps. They shape planner search. Changing them can alter planning time and can also alter the set of join orders available for consideration.</p> https://nalar.dev/postgresql-memoize-caches-parameterized-scan-results/ Mon, 14 Sep 2026 00:00:00 +0700 https://nalar.dev/postgresql-memoize-caches-parameterized-scan-results/ <p>A nested-loop join can execute its inner plan many times. When that inner plan is parameterized by values from the outer side, repeated outer values can trigger the same inner lookup again and again. PostgreSQL can place a <code>Memoize</code> node above the parameterized scan so a later lookup with the same parameter key can reuse rows already produced.</p> <p>Memoization does not change join semantics and it does not create a persistent cache. It is an executor-level optimization attached to a particular query plan, with entries that exist only for that execution.</p>