pá 2. 6. 2023 v 3:45 odesílatel James Pang (chaolpan)
napsal:
>these lines about "SPI Plan" are these PL/PGSQL functions related
> SPI_prepare plan entry, right? Possible to set a GUC to max(cached plan)
> per backend ?
>
There is no limit for size of system cache. You can use pgbouncer
these lines about "SPI Plan" are these PL/PGSQL functions related
SPI_prepare plan entry, right? Possible to set a GUC to max(cached plan) per
backend ?
SPI Plan: 1024 total in 1 blocks; 600 free (0 chunks); 424 used
CachedPlan: 2048 total in 2 blocks; 304 free (1 chunks); 1744
Thanks for your replies, you were totally right, it was due to the CPU
governor: the governor was set to 'powersave'. I've changed it to
'performance' and the server is flying now. I'm still working on it,
but the first quick tests I've made are showing much better numbers.
Those simple short
On Thu, 2023-06-01 at 08:50 +, James Pang (chaolpan) wrote:
> we found thousands of cached plan , since JDBC driver only allow max 256
> cached
> prepared statements, how backend cache so many sql plans. If we have one
> function,
> when application call that function will make backend to
Yes, too many cached metadata and we are thinking of a workaround to
disconnect the sessions timely.
In addition, based on the dumped memory context, I have questions
1) we found thousands of cached plan , since JDBC driver only allow max 256
cached prepared statements, how backend cache
Hi
čt 1. 6. 2023 v 8:53 odesílatel Laurenz Albe
napsal:
> On Thu, 2023-06-01 at 03:36 +, James Pang (chaolpan) wrote:
> > PG V14.8-1 , client using Postgresql JDBC driver we found 40MB process
> memory per
> > backend, from Operating system and memorycontext dump “Grand total:”,
> both
On Thu, 2023-06-01 at 03:36 +, James Pang (chaolpan) wrote:
> PG V14.8-1 , client using Postgresql JDBC driver we found 40MB process memory
> per
> backend, from Operating system and memorycontext dump “Grand total:”, both
> mached.
> But from details, we found almost of entry belong to
