Re: [PATCH v1] Stale row estimates for transition tables

I did some further measurements of v1 with small, frequent UPDATEs. Even
when the transition table row count stayed the same, repeating analysis,
rewriting and planning added about 14 us per UPDATE for a count query and
48 us for a single-row audit INSERT in my local -O2 tests. The execution
plans were unchanged, so this was an unnecessary cost in these cases.

The attached v2 checks ENR metadata before reusing a cached query. It
compares the ENR type, backing relation OID and row count with the cached
RTE. If they match, the analyzed query and execution plan are reused. If
an ENR is missing or the metadata differs, the existing invalidation path
repeats analysis, rewriting and planning with the current query environment.

v2 records pointers to the ENR RTEs when the query trees are built, so reuse
only checks those entries rather than walking the whole query tree. ENRs
with a directly supplied TupleDesc are still conservatively reanalyzed,
since their structural changes are not covered by catalog invalidation.
As in v1, this applies only to cached sources with a raw parse tree.

In the fixed-row-count tests, v2 retained the cached plans after warmup.
The original 0-to-2000-row case still switched from Nested Loop to Merge
Join, with only one replan across six subsequent UPDATEs. Row counts that
change on every execution will still cause reanalysis on every execution.

Does this approach seem reasonable?

Thanks,
Teletele