Re: Postgresql JDBC process consumes more memory with partition tables update delete

Vladimir Sitnikov <sitnikov.vladimir@gmail.com>

From: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
To: "James Pang (chaolpan)" <chaolpan@cisco.com>
Cc: "pgsql-jdbc@lists.postgresql.org" <pgsql-jdbc@lists.postgresql.org>
Date: 2022-09-08T09:55:38Z
Lists: pgsql-performance
> interesting thing is we only see this issue by JDBC driver client

First of all, it turns out that a single UPDATE statement consumes 4M

Then, it looks like you have **multiple** UPDATE statements in the
server-side cache.
It does sound strange that a single backend contains multiple entries
for the same SQL text.

1) Would you please double-check that SQL text is the same. Do you use
bind variables?
2) Would you please double-check that you close statements after use
(e.g. try-with-resources).


CachedPlan: 4204544 total in 13 blocks; 489400 free (4 chunks);
3715144 used: UPDATE WBXMEETINGINS

Frankly speaking, I am not sure the JDBC driver is in a position to
predict that a single-line statement would consume that much
server-side memory.

It would be nice if backend devs could optimize the memory consumption
of the cached plan.
If optimization is not possible, then it would be nice if the backend
could provide clients with memory consumption of the cached plan.
In other words, it would be nice if there was a status message or
something that says "ok, by the way, the prepared statement S_01
consumes 2M".

James, the captured dump includes only the first 100 entries.
Would you please try capturing more details via the following command?

MemoryContextStatsDetail(TopMemoryContext, 1000, true)

(see https://github.com/postgres/postgres/blob/adb466150b44d1eaf43a2d22f58ff4c545a0ed3f/src/backend/utils/mmgr/mcxt.c#L574-L591
)


Vladimir



Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Fix recovery_prefetch with low maintenance_io_concurrency.