| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, gzh <gzhcoder(at)126(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Different execution plan between PostgreSQL 8.4 and 12.11 |
| Date: | 2022-10-11 14:30:53 |
| Message-ID: | Y0V+HaTMlgt04hk3@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Oct 11, 2022 at 09:59:43AM -0400, Tom Lane wrote:
> David Rowley <dgrowleyml(at)gmail(dot)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.
We do have a correlation statistics value for each column but I am
unclear if that would help here.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com
Indecision is a decision. Inaction is an action. Mark Batterson
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Lelarge | 2022-10-11 15:51:46 | Weird planner issue on a standby |
| Previous Message | Tom Lane | 2022-10-11 13:59:43 | Re: Different execution plan between PostgreSQL 8.4 and 12.11 |