diff --git a/README.md b/README.md
index f4831e5..ae86613 100644
--- a/README.md
+++ b/README.md
@@ -171,6 +171,9 @@ And this time, the specific configuration is applied.
 Caveats
 --------
 
+`pg_query_settings` doesn't work well with **prepared queries**. These are
+considered as not supported yet. This will be fixed in future releases.
+
 Enabling this extension might have a performance impact on any workloads
 with a high number of fast queries, as it slighlty increases the time taken
 to compute the query plan. The more entries in the table, the greater the
diff --git a/pg_query_settings.c b/pg_query_settings.c
index 24194da..6f8b841 100644
--- a/pg_query_settings.c
+++ b/pg_query_settings.c
@@ -298,6 +298,16 @@ 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. 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`
+   * 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)