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

From: Richard Guo <guofenglinux(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, bryfox(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19007: Planner fails to choose partial index with spurious 'not null'
Date: 2025-09-01 06:00:03
Message-ID: CAMbWs4-o9CUDe2dERGxmq7D4Ha0bC=QGhZfAwyxomw_Me08KoQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Aug 22, 2025 at 4:25 PM Richard Guo <guofenglinux(at)gmail(dot)com> wrote:
> 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?

0001 has been pushed; here is a rebase of 0002.

I think the additional call to eval_const_expressions() is acceptable
performance-wise, because 1) it only runs when index expressions or
predicates are present, and 2) it's relatively cheap when run on small
expression trees, which is typically the case for index expressions
and predicates. In return, in cases such as the reported, it enables
the planner to match and use partial indexes, which can be a big win
in execution.

- Richard

Attachment Content-Type Size
v3-0001-Fix-const-simplification-for-index-expressions-an.patch application/octet-stream 7.3 KB

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Richard Guo 2025-09-01 07:32:43 Re: BUG #19037: Planner fails on estimating array length with "no relation entry" error
Previous Message Alexander Korotkov 2025-08-31 22:13:47 Re: BUG #19031: pg_trgm infinite loop on certain cases