High memory usage in CachedPlan for large IN clauses in partitioned table updates

Hi, Recently, I noticed that while I used pgjdbc to batch update a partition table, Cacheplan can sometimes use a lot of memory, this problem occurs in more Postgresql backend processes, which amplifies the impact. I tried to repeat this question in my test environment. The testing query (more t

Re：Limit length of queryies in pg_stat_statement extension

Hi, Thanks for your answer. > I don't think that it would move the needle much. Deallocating entries is > very > expensive, even when the query text file isn't being cleaned up, as it needs > to > sort all entries by usage to remove the least recently used all with an > exclusive pgss->lock.

Limit length of queryies in pg_stat_statement extension

Hi all, Recently, I have noticed a potential problem in the pg_stat_statements extension. When the garbage collection is triggered within this extension, if there is a significant amount of data to be written to the pgss_query_texts.stat file (for example, when tracking very long SQL queries), t

sublink [exists (select xxx group by grouping sets ())] causes an assertion error

Hello postgres hackers: I recently notice these sql can lead to a assertion error in pg14 and older version. Here is an example: postgres=> CREATE TABLE t1 (a int); CREATE TABLE postgres=> INSERT INTO t1 VALUES (1); INSERT 0 1 postgres=> SELECT EXISTS ( SELECT * FROM t1 GROUP BY GROUPING SETS ((