Skip to content

Commit

Permalink
fix up previous commit (after review of ioguix and gleu)
Browse files Browse the repository at this point in the history
  • Loading branch information
yhuelf committed Sep 8, 2023
1 parent 48c322e commit 0578158
Show file tree
Hide file tree
Showing 2 changed files with 10 additions and 1 deletion.
5 changes: 4 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
Expand Up @@ -174,7 +174,10 @@ Caveats
`pg_query_settings` doesn't work well with **prepared queries**. More specifically:
for a given parameter `P`, if the generic plan is selected, and if the executor
needs to fetch the value of `P`, then it won't get the value specified in the
`pgqs_config` table. For example, the executor fetches the value of `work_mem`
`pgqs_config` table: at this point the value would have been reset to its default.
This will be fixed in future releases.

For example, the executor fetches the value of `work_mem`
in order to decide whether to perform an in-memory sort, while the parameter
`max_parallel_workers_per_gather` is only used during the planification stage,
so `pg_query_settings` only works for this last example.
Expand Down
6 changes: 6 additions & 0 deletions pg_query_settings.c
Original file line number Diff line number Diff line change
Expand Up @@ -298,6 +298,12 @@ execPlantuner(Query *parse, const char *query_st, int cursorOptions, ParamListIn
static void
PlanTuner_ExecutorEnd(QueryDesc *q)
{
/* FIXME: here, we restore the value of each parameter, but that's a problem
* for prepared queries. For example, the executor fetches the value of work_mem
* in order to decide whether to perform an in-memory sort, but at this point the
* value would have been reset to its default (at the end of the PREPARE statement).
* However, there's no problem with parameters that only affect planification, such
* as max_parallel_workers_per_gather. */
DestroyPRList(true);

if (prev_ExecutorEnd)
Expand Down

0 comments on commit 0578158

Please sign in to comment.