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 →
  1. Use Limit instead of Unique to implement DISTINCT, when possible