Re: Different execution plan between PostgreSQL 8.4 and 12.11
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: gzh <gzhcoder@126.com>, pgsql-general@lists.postgresql.org
Date: 2022-10-11T13:59:43Z
Lists: pgsql-general
David Rowley <dgrowleyml@gmail.com> writes: > It feels like something is a bit lacking in our cost model here. I'm > just not sure what that is. The example you show is the same old problem that we've understood for decades: for cost-estimation purposes, we assume that matching rows are more or less evenly distributed in the table. Their actual location doesn't matter that much if you're scanning the whole table; but if you're hoping that a LIMIT will be able to stop after scanning just a few rows, it does matter. While it'd be pretty easy to insert some ad-hoc penalty into the LIMIT estimation to reduce the chance of being fooled this way, that would also discourage us from using fast-start plans when they *do* help. So I don't see any easy fix. regards, tom lane
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Use Limit instead of Unique to implement DISTINCT, when possible
- 5543677ec90a 16.0 landed