Re: BUG #18643: EXPLAIN estimated rows mismatch

From: David Rowley <dgrowleyml(at)gmail(dot)com>
To: ming wei tan <mingwei(dot)tc(at)gmail(dot)com>
Cc: Andrei Lepikhov <lepihov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18643: EXPLAIN estimated rows mismatch
Date: 2024-10-02 20:57:48
Message-ID: CAApHDvqqQrVeZ0A5eyPDwOpFRA=xGHgKZp=iY3gKU4gZ4UyVwg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Thu, 3 Oct 2024 at 07:17, ming wei tan <mingwei(dot)tc(at)gmail(dot)com> wrote:
>
> On 1/10/2024 18:43, Tom Lane wrote:
> > In any case, in this toy example that lacks an ANALYZE step,
> > the selectivity estimates are mostly going to be garbage.
>
> Thanks for the replies. I'm just checking if a bug is present here
> is a bug. Even with ANALYZE, the first EXPLAIN estimates more rows
> compared to the second, even though the second WHERE clause is
> less restrictive.

I think you already checked that and Tom answered mentioning the
reason that this happens.

We certainly could do better here, but, as Tom mentioned your example
does not seem convincing enough to warrant much effort.

You should read the commit message in [1] as that might help you
understand the project's point of view for these sort of
optimisations. See in particular the first sentence of the second
paragraph.

David

[1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=8ec5429e2f422f4d570d4909507db0d4ca83bbac

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2024-10-03 01:12:48 Re: PostgreSQL 17 Segmentation Fault
Previous Message Sean Massey 2024-10-02 20:08:14 Re: PostgreSQL 17 Segmentation Fault