Re: SQLFunctionCache and generic plans

In the department of no-good-deed-goes-unpunished ...

I noticed that avocet and trilobite (two of our CLOBBER_CACHE_ALWAYS
animals) have started to fail on the deadlock-parallel isolation
test, with symptoms that look like they're timing out.  Poking at
it here with a somewhat faster machine (a Mac M4), I see that under
debug_discard_caches=1 that test went from

ok 27        - deadlock-parallel                       26362 ms

immediately before commit 0dca5d68d to

ok 27        - deadlock-parallel                      267869 ms

immediately after.  This is evidently because the test involves a lot
of evaluations of an intentionally-not-inline-able SQL function.
Previously we cached the plans for that function for the life of the
outer query, but now they're getting clobbered and rebuilt each time.

This is not wrong; the wrong behavior was hanging onto a
potentially-obsolete plan.  But it's pretty unfortunate for the
runtime of this test under debug_discard_caches=1.

The simplest fix is to force that test to use debug_discard_caches=0,
but I don't love that answer.  Anybody have a better idea?

It looks like the runtime of the infinite_recurse test on these
animals has taken a hit too for the same reason, and there may be
other places.

			regards, tom lane