Peter Geoghegan <pg@bowt.ie> writes:
> Are you sure that it would really be worth the trouble of caching our
> answer? It's not clear that that has only minimal maintenance burden.
I'd be inclined to do so if we can find a suitable place to put it.
But wouldn't a field in IndexInfo serve? Letting the field default
to "not optimizable" would cover most cases.
> The fact is that most individual aminsert() calls that get the hint
> will never actually apply it in any way.
Yeah, you could make an argument that just not trying to optimize when
there are index expressions would be fine for this --- and we may have
to fix it that way in v14, because I'm not sure whether adding a field
in IndexInfo would be safe ABI-wise. But ISTM that the overhead of
index_unchanged_by_update is a bit more than I care to pay per row
even when it's only considering plain index columns. I'm generally
allergic to useless per-row computations, especially when they're
being added by an alleged performance improvement.
Another thing we ought to check into is the extent to which this
is duplicative of the setup calculations for HOT updates --- I seem
to recall that there's already roughly-similar logic somewhere else.
And, not to be too picky, but does this cope with the case where
an indexed column is changed by a BEFORE trigger, not by the
query proper?
regards, tom lane