【标题描述】: JDBC进行批量插入时，preparedStatementCacheQueries参数不生效，数据库端cachedplan数据上升较快
【测试类型：SQL功能/存储功能/接口功能/工具功能/性能/并发/压力长稳/故障注入/安全/资料/编码规范】【测试版本：5.1.0】 问题描述： JDBC进行批量插入时，preparedStatementCacheQueries参数不生效，数据库端cachedplan数据上升较快，远大于preparedStatementCacheQueries数量。
【操作系统和硬件信息】(查询命令: cat /etc/system-release, uname -a):
windows
【测试环境】(单机/1主x备x级联备):
单机
【被测功能】:
jdbc批量插入
【测试类型】:
不涉及
【数据库版本】(查询命令: gaussdb -V):
5.1.0 release
【预置条件】:
数据库功能正常。
【操作步骤】(请填写详细的操作步骤):
配置batchMode=OFF&&reWriteBatchInserts=true后，单次插入1000条以上数据：

        Properties props = new Properties();
        props.put("preparedStatementCacheQueries", "2");
        props.put("prepareThreshold", "1");
        props.put("fetchSize", "5");
        props.put("batchMode", "OFF");
        props.put("reWriteBatchedInserts", "true");
        try (Connection conn = TestUtil.openDB(props)) {
            excuteSql(conn, "set session_timeout = 0;");
            excuteSql(conn, "drop table if exists t1");
            excuteSql(conn, "create table t1(id int, id1 int, id2 int, id3 int, id4 int, id5 int, data varchar(2048));");
            String batchInsert = "insert into t1 values (?,?,?,?,?,?,?)";
    ....反复执行批量插入(1000以上/次)

2. 在此过程中通过下面的语句查看cachedplan数量(application_name需要修改)，
   select a.sessid, a.contextname, count() as count from gs_session_memory_detail a left join pg_stat_activity b on regexp_replace(sessid, '^[^.].','') = b.sessionid where b.application_name like '%Driver Tests%' and a.contextname='CachedPlan' group by a.sessid, a.contextname order by 3 desc;
   3.重复1/2步骤，并且访问不同的表，查看cachedplan是否持续上升
   【预期输出】:
   步骤2输出的数量应该接近preparedStatementCacheQueries=2，误差在1以内。
   步骤3：cachedplan数量不会持续上升。
   【实际输出】:
   步骤2输出的cachedplan数量远多于preparedStatementCacheQueries数量
   步骤3：cachedplan数量持续上升
   【原因分析】:
3. 这个问题的根因
   batchmode为off和开启rewrite后出现过多cacheplan原因已定位，因为此过程会将批量数据按128到1进行分组，如1000按照128分组成7个128 ,1个 64，1个32，1个8共10条sql，这10条语句不进入lru cache管理，单次批量插入所以只会通过java gc释放。默认的10s gc周期内，有多个大于128的批量插入，那么jdbc会向数据库申请对应数量的cachedplan且不受lru cache数量限制；
   解决措施：

• 开启batchmode,这样批量插入语句不会改写且纳入lru cache管理，使用后那释放
• batchmode= off但不开启rewrite，这样会增加更多的网络通信开销
• batchmode= off 开启rewrite,减少gc周期。

2. 问题推断过程
3. 还有哪些原因可能造成类似现象
4. 该问题是否有临时规避措施
5. 问题解决方案
6. 预计修复问题时间

【日志信息】(请附上日志文件、截图、coredump信息):

【测试代码】: