Re: Bad estimate with partial index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
Cc: André Hänsel <andre(at)webkr(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Bad estimate with partial index
Date: 2022-04-20 19:03:25
Message-ID: 2943313.1650481405@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> writes:
> But dependencies.c might need a fix too, although the issue is somewhat
> inverse to this one, because it looks like this:

> if (IsA(clause, RestrictInfo))
> {
> ... do some checks ...
> }

> so if there's no RestrictInfo on top, we just accept the clause. I guess
> this should do the same thing with checking relids like the fix, but
> I've been unable to construct an example demonstrating the issue (it'd
> have to be either pseudoconstant or reference multiple rels, which seems
> hard to get in btcostestimate).

Hm. You could get an indexqual referencing other rels when considering
doing a join via a nestloop with parameterized inner indexscan. However,
that would always be a query WHERE clause, which'd have a RestrictInfo.
At least in this code path, a bare clause would have to be a partial
index's predicate, which could not reference any other rels. The
pseudoconstant case would require a predicate reducing to WHERE FALSE
or WHERE TRUE, which is at best pointless, though I'm not sure that
we prevent it.

You might have to go looking for other code paths that can pass a
bare clause if you want a test case for this.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Thomas Munro 2022-04-20 19:07:28 Re: pg14 psql broke \d datname.nspname.relname
Previous Message Tom Lane 2022-04-20 18:34:52 Re: preserving db/ts/relfilenode OIDs across pg_upgrade (was Re: storing an explicit nonce)