Closed kfuru closed 1 year ago
Hi Furutani-san,
Thanks for the report. I'll fix the problem.
@michaelpq @horiguti Since there is the reproducer and the proposal to fix it, I think I can tackle it. I'm going to start to fix it in August. Is it okay?
I think I can tackle it. I'm going to start to fix it in August. Is it okay?
If you think you can handle it, that's OK by me!
I think I can tackle it. I'm going to start to fix it in August. Is it okay?
If you think you can handle it, that's OK by me!
Yeah, right. Thanks!
Message ID: @.***>
@kfuru Is there a workaround for this issue before the patched pg_hint_plan comes out? We are currently using the PG11 version in a Centos 7 environment.
@jjune235
Is there a workaround for this issue before the patched pg_hint_plan comes out? We are currently using the PG11 version in a Centos 7 environment.
I haven't tried it with CentOS7 and PG11, disabling plan caching for PreparedStatements may help prevent fluctuations in execution plans.
But, these approach may not benefit from the PreparedStatement cache.
Add prepareThreshold=0 to JDBC connection parameters.
jdbc:postgresql://localhost/test?prepareThreshold=0
Or, disable preparedstatement cache for that statement only.
example: PreparedStatement pstmt1 = conn.prepareStatement(sql1); org.postgresql.PGStatement pgs1 = pstmt1.unwrap(org.postgresql.PGStatement.class); //ADD pgs1.setPrepareThreshold(0); //ADD
@yamatattsu What's your status on this one? I'd like to do a new release by the next two weeks to catch up with PostgreSQL 16 itself, and addressing this issue would be nice.
@michaelpq
What's your status on this one? I'd like to do a new release by the next two weeks to catch up with PostgreSQL 16 itself, and addressing this issue would be nice.
I started to fix that from last week. But I thought that I was going to fix this by mid-October as same as the Japanese document fix. If your deadline to fix the bug is by the end of this week or next week, I don't think I can handle that.
I started to fix that from last week. But I thought that I was going to fix this by mid-October as same as the Japanese document fix. If your deadline to fix the bug is by the end of this week or next week, I don't think I can handle that.
Okay, I'll take care of it myself, then.
Checked, re-checked and applied a fix to all the branches, taking into account that the compilation of plpgsql_recurse_level is much more precise in PG16 and master.
Hello, When use JDBC's prepared Statement, HINT not work in the middle of the process. This is presumably due to the effect of preparedStatement on the execution plan cache, but after a certain number of executions, the hint clause is ignored. In the following (Test3, Test4), the hint clause is ignored after the 6th execution, even though a hint clause is specified.
How to reproduce:
Probably, pg_hint_plan_post_parse_analyze() in pg_hint_plan.c is not called for the 6th time in the SQL using the HINT clause, so current_hint_retrieved=false is not executed. https://github.com/ossc-db/pg_hint_plan/blob/PG15/pg_hint_plan.c#L2986
It seems that Yugabyte DB developers are also encountering the same problem. https://github.com/yugabyte/yugabyte-db/issues/12741
Since developer of yogabytedb seem to be resolved, is it possible to reflect this in the official's pg_hint_plan? https://github.com/yugabyte/yugabyte-db/commit/c303cebfaa0e73335ca54c173b352c235226e53e#diff-759bfed57e55331cff5c07c3de8b73268ec85205703e127f5ac2cf0974eb4e2d
In PostgreSQL15, I fixed as follows.
After fixed.
If there is no problem with this fix, I think you could reflect it. And it seems to be the same for pg_hint_plan14 and earlier versions.
Regards, kfuru