Closed come25136 closed 1 year ago
MEMO
I tried enum select with pg_hint_plan.debug_print = verbose
and found that LOG: pg_hint_plan[qno=0x9]: planner: no valid hint
was output for all queries.
This is not a misdescription, but actually qno=0x9
for all of them.
When run from psql, qno was incremented correctly.
pg_hint_plan[qno=0x2e]: planner
My guess, following the code from the logs, is that it's probably coming here.
https://github.com/ossc-db/pg_hint_plan/blob/69747ab73062d763391ef6fc0ab17db49673ee74/pg_hint_plan.c#L3054 or https://github.com/ossc-db/pg_hint_plan/blob/69747ab73062d763391ef6fc0ab17db49673ee74/pg_hint_plan.c#L3069
I can't write c lang and am not a postgres expert, so I'm closing the investigation once and for all. If anyone can help me, I'd be super grateful for your help.
p.s. We'll investigate when we can afford it, but don't expect much.
I have increased the debug log and found that current_hint_str is null. https://github.com/ossc-db/pg_hint_plan/blob/69747ab73062d763391ef6fc0ab17db49673ee74/pg_hint_plan.c#L3053
I have increased the debug log and found that current_hint_retrieved is true. https://github.com/ossc-db/pg_hint_plan/blob/733b41855071f65c655ae8d95b36da70e2b74f29/pg_hint_plan.c#L2834
I observed that plpgsql_recurse_level is 0. https://github.com/ossc-db/pg_hint_plan/blob/733b41855071f65c655ae8d95b36da70e2b74f29/pg_hint_plan.c#L3033
From the behavior, I guess that "current_hint_retrieved" does not seem to be reset (assigned false).
Not sure if this is the correct fix, but I have found that adding current_hint_retrieved = false;
to the line below current_hint_state = NULL;
is a workaround.
// Modified code
msgqno = qno;
}
current_hint_state = NULL;
current_hint_retrieved = false; // ← add code
if (prev_planner)
result = (*prev_planner) (parse, query_string,
I have pushed this workaround to my repository. https://github.com/come25136/pg_hint_plan/commit/76df17fda69ac5bdca10e75ecdea9da16dc6c7b7
I was looking at what you have here, and this looks incorrect to me, as current_hint_retrieved's fate is now linked to current_hint_str but not current_hint_state which is what you are attempting to enforce here. It is true that the logic of the code between the state, this boolean and the string involved depending on the depth of the calling stack is confusing.
Anyway, this issue is a duplicate of #145 which is presenting a different approach to reset the flag using an executor hook. So I am closing this one as a duplicate as the patch posted there looks more promising.
Hello! I have noticed that in some cases when using prisma in node.js, for some reason the hint clause does not work. When I run the same query in psql it works, but not when I run it from prisma($queryRaw). Here is the log on the postgresql side when the query clause does not work.
The logs show that apparently queries are being issued in prisma other than the expected query. This seems to be issued when selecting an enum column, and I found that the query clause is not working because of this. The essential cause is not compatibility with prisma, but that there is another query between
2023-06-23 00:23:34.953 UTC [68] LOG: duration: 1.246 ms parse
and2023-06-23 00:23:34.964 UTC [68] LOG: duration: 3.661 ms
and the order of execution is not serial.For reference, here is the log when the query clause is working. You can see that
LOG: pg_hint_plan
is being output.I used DeepL translation, so I may write strange things. I'm sorry.