|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Subject:||Re: Release SPI plans for referential integrity with DISCARD ALL|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
yuzuko <yuzukohosoya(at)gmail(dot)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
regards, tom lane
|Next Message||Efrain J. Berdecia||2021-09-26 20:11:07||Add create and update timestamp to all objects|
|Previous Message||Isaac Morland||2021-09-26 17:58:07||Re: Add missing function abs (interval)|