Re: BUG #19007: Planner fails to choose partial index with spurious 'not null'

Richard Guo <guofenglinux@gmail.com>

From: Richard Guo <guofenglinux@gmail.com>
To: David Rowley <dgrowleyml@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, bryfox@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2025-08-22T07:25:25Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix const-simplification for index expressions and predicate

  2. Fix const-simplification for constraints and stats

Attachments

On Wed, Aug 20, 2025 at 6:37 PM Richard Guo <guofenglinux@gmail.com> wrote:
> I've had some time to look at this issue again.  There are several
> cases in plancat.c where specific expressions need to be run through
> eval_const_expressions because the planner will be comparing them to
> similarly-processed qual clauses.  This includes constraint
> expressions, statistics expressions, index expressions and index
> predicates -- as highlighted by this bug report.

I've split the patch into two.  0001 fixes const-simplification for
constraint expressions and statistics expressions by ensuring that
Vars are updated to have the correct varno before
const-simplification, and that a valid root is passed to
eval_const_expressions.  0002 fixes const-simplification for index
expressions and predicate by running eval_const_expressions a second
time after the Vars have been fixed and with a valid root.

I think 0001 is in pretty good shape.  I'm concerned that in 0002 we
have to run eval_const_expressions twice.  I once considered caching
the untransformed index expressions and predicate, and running
const-simplification outside of relcache.c.  However, that doesn't
seem like a better solution, since we would need to re-run
const-simplification every time we fetch the index expressions and
predicate.  Any suggestions?

Thanks
Richard