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 |
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 |