yuzuko 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 lik
On Wed, Mar 10, 2021 at 1:49 PM yuzuko wrote:
>
> Hello,
>
> I thought about this suggestion again.
>
> Amit's patch suggested in the thread [1] can eliminate SPI plans from
> INSERT/UPDATE triggers, so our memory pressure issue would be solved.
> But as far as I can see that thread, Amit's patch
Hello,
I thought about this suggestion again.
Amit's patch suggested in the thread [1] can eliminate SPI plans from
INSERT/UPDATE triggers, so our memory pressure issue would be solved.
But as far as I can see that thread, Amit's patch doesn't cover DELETE case.
It is not a common case, but there
Hello,
Thank you for your comments.
Following Corey's advice, I applied Amit's patches proposed in this
email [1], and confirmed our memory pressure problem was solved.
So dropping cached plan with DISCARD is not necessary anymore.
[1]
https://www.postgresql.org/message-id/CA%2BHiwqG1qQuBwApueaU
On 2021-01-13 09:47, yuzuko wrote:
But we are also considering another option to solve this problem, which
makes users to release cached SPI plans for referential integrity as well as
plain cached plans with DISCARD ALL. To do that, we added a new
function, RI_DropAllPreparedPlan() which deletes
Hi Corey,
Thank you for sharing.
> Amit's patch is now available in this thread [1]. I'm curious if it has any
> effect on your memory pressure issue.
>
I just found that thread. I'll check the patch.
--
Best regards,
Yuzuko Hosoya
NTT Open Source Software Center
On Wed, Jan 13, 2021 at 1:03 PM Corey Huinker
wrote:
> In addition to that, a following case would be solved with this approach:
>> When many processes are referencing many tables defined foreign key
>> constraints thoroughly, a huge amount of memory will be consumed
>> regardless of whether refe
>
> In addition to that, a following case would be solved with this approach:
> When many processes are referencing many tables defined foreign key
> constraints thoroughly, a huge amount of memory will be consumed
> regardless of whether referenced tables are partitioned or not.
>
> Attached the p
Hello,
We found problem that a huge amount of memory was consumed when
we created a foreign key on a partitioned table including a lots partitions
and accessed them, as discussed in [1]. Kuroda-san's idea proposed in
this thread is reducing cached SPI plans by combining several plans into one.
Bu
