Re: BUG #19784: "no relation entry for relid 1" when costing = ANY (<array expr over max(col)>) in a MinMaxAggPath

From: shihao zhong <zhong950419(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Richard Guo <guofenglinux(at)gmail(dot)com>, alpkeles99(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19784: "no relation entry for relid 1" when costing = ANY (<array expr over max(col)>) in a MinMaxAggPath
Date: 2026-10-26 04:01:34
Message-ID: CAGRkXqTsQBiG_JL_zAOyAV+MaYgn_OHmViB27nGzkezuVMk==A@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi Tom,

> I'm not so sure :-(. Looking at the last example you showed...

I think I was over optimistic earlier. I took a look this afternoon
and I think you are right here. So the idea is WHERE is simplified
earlier and not able to see the stats, but the CHECK can.

> So I think the only really acceptable answer here is going to be to
> fix things so we don't try to do eval_const_expressions until we've
> loaded up all the RelOptInfo statistical data.

I am not sure we can postpone the WHERE clause, since it is
simplified before any RelOptInfo exists. That feels like a very big change.
Could we load the column stats first instead? We already
do that for NOT NULL columns in preprocess_relation_rtes.

Thanks,
Shihao

In response to

Browse pgsql-bugs by date

  From Date Subject
Previous Message Hayato Kuroda (Fujitsu) 2026-10-26 02:56:10 RE: BUG #19795: pgoutput: walsender crashes on START_REPLICATION option without a value