The other thing that emerged from
http://www.postgresql.org/message-id/flat/CAOR=d=3j1U_q-zf8+jUx1hkx8ps+N8pm=EUTqyFdJ5ov=+fawg(at)mail(dot)gmail(dot)com
is that for workloads like this, OverrideSearchPathMatchesCurrent is
a bottleneck: it's part of the code path needed to re-use a cached plan,
and this example is doing a lot of that. The original implementation
of that function followed the KISS principle, since I thought it probably
wouldn't be a bottleneck. Now that that's proven wrong, I offer the
attached reimplementation, which saves about 9% of overall runtime on
Scott's example by avoiding palloc/pfree traffic. It knows a lot more
about the relation of override search paths to active search paths than
it did before; but the adjacent functions know these things too, so it
doesn't seem like much of a loss from a maintainability standpoint.
regards, tom lane