Re: Release SPI plans for referential integrity with DISCARD ALL

yuzuko <yuzukohosoya@gmail.com> writes:
> I improved a patch according to Peter's following comment :

>> but I think the
>> solution of dropping all cached plans as part of DISCARD ALL seems a bit
>> too extreme of a solution.  In the context of connection pooling,
>> getting a new session with pre-cached plans seems like a good thing, and
>> this change could potentially have a performance impact without a
>> practical way to opt out.

> In a new patch, I separated discarding SPI Plan caches for RI from DISCARD ALL
> and added a new option "RIPLANS" to DISCARD command to do that.

I'm not really comfortable with exposing this as a user-visible behavior.
In particular ...

> The amount of modification is small and this option can be
> removed instantly when it is no longer needed, so I think we can use
> this patch as a provisional solution.

... this claim seems like nonsense.  Once there is user-accessible syntax
for something, we basically can't ever take that out, because it'd break
applications that call that command.

It seems like the real problem with the ri_query_cache cache is that
it will grow without limit.  I wonder whether it wouldn't be better
to put some upper bound on it, along with a simple least-recently-used
rule to choose which entry to discard.  (Perhaps the same goes for
ri_constraint_cache and/or ri_compare_cache, although their entry sizes
are smaller.)

            regards, tom lane