Re: Indexes on expressions with multiple columns and operators

=?UTF-8?Q?Fr=C3=A9d=C3=A9ric_Yhuel?= <frederic(dot)yhuel(at)dalibo(dot)com> writes:
> On 9/18/25 18:40, Tom Lane wrote:
>> The attached fixes things so it works like it did pre-a391ff3c3.

> Indeed, it works well!

Thanks for testing!

>> I spent some time trying to devise a test case, and was reminded
>> of why I didn't have one before: it's hard to make a case that
>> will be robust enough to not show diffs in the buildfarm.
>> I'll keep thinking about that though.

> It looks like an interesting homework for an aspiring hacker :-)
> So I'll try to devise one, too.

I concluded that maybe I was overthinking this part. We only really
need to check the rowcount estimate, since the indexscan cost estimate
is already okay. And stats_ext.sql seems to have gotten away with
assuming that rowcount estimates are reliably reproducible on
not-too-large tables. This bug affects use of extended statistics
too, so a test using those is good enough to show it's fixed; we don't
really need to use an expression index for the purpose. So, I added a
test case in stats_ext.sql and pushed it.

I wish we could back-patch this, since it's so obviously a bug fix.
But we avoid changing plans in released branches, and at this point
it's even too late for v18.

Thank you again for the report.

regards, tom lane