yuzuko <yuzukohos...@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
