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

shihao zhong <zhong950419(at)gmail(dot)com> writes:
>> So even with a fix that prevents examine_variable from failing, it
>> seems likely that we are not managing to reduce index expressions the
>> same as we will reduce query expressions later.

> I think they are ok. The NullTest reduction in c925ad30b only needs the
> RTE and array, not the RelOptInfo. And query quals are also folded before
> any RelOptInfo exists.

I'm not so sure :-(. Looking at the last example you showed, the
failure occurs because when we do eval_const_expressions on the index
expression, we call elem_contained_by_range_support to see if it can
replace the <@ operator with something else. That calls
cost_qual_eval_node, and that's what ultimately hits the
examine_variable failure. However, even if we band-aid that to not
fail, we are far from being okay. Because what
elem_contained_by_range_support is going to do with the cost estimate
is decide whether or not to transform the <@ operator to something
else. Presumably, whoever wrote that code verified that it did
something useful, so there must be code paths where it doesn't fail
because the underlying RelOptInfo is available, and so more than
one transformation behavior is possible.

Now, it's a fundamental requirement of the optimizer that
eval_const_expressions will give the same result on multiple copies of
the same expression. Years ago that was safe because it didn't try to
look at any statistical data, or indeed much of anything except the
presented expression tree. But we've now injected variable statistics
into its behavior, and that is a problem, not least because it's not
obvious that elem_contained_by_range_support is doing something it
shouldn't. (There are probably other functions doing the same, and
even if we got rid of every case, people would keep trying to do
that.) If we band-aid examine_variable to not fail depending on
context, we will mask places that are not producing the same results,
and I don't think we can expect to get away with that for long.

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. At the least, that'll
require postponing simplification of index expressions until their
baserels' data is available, as well as figuring out where we can
postpone preprocess_minmax_aggregates to, plus whatever else turns
out to be jumping the gun. That does not sound like it'll be a
back-patchable fix. So maybe in the back branches we have to do
what I posted upthread, but I'm not happy with it as a permanent fix.

regards, tom lane