From a7d3c2348d75f2501ae60fbfbbe027cbb5ae2ec6 Mon Sep 17 00:00:00 2001
From: "Stephen R. van den Berg" <srb@cuci.nl>
Date: Fri, 28 Jul 2017 15:45:20 +0200
Subject: [PATCH] pgsql: Document implementation decision.
---
lib/modules/Sql.pmod/pgsql_util.pmod | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/lib/modules/Sql.pmod/pgsql_util.pmod b/lib/modules/Sql.pmod/pgsql_util.pmod
index 7094634188..2095d48d3b 100644
--- a/lib/modules/Sql.pmod/pgsql_util.pmod
+++ b/lib/modules/Sql.pmod/pgsql_util.pmod
@@ -67,7 +67,16 @@ final Regexp transendprefix
=iregexp("^\a*(COMMIT|ROLLBACK|END)([; \t\f\r\n]|$)");
/* For statements matching execfetchlimit the resultrows will not be
- * fetched in pieces
+ * fetched in pieces. This heuristic will be sub-optimal whenever
+ * either an UPDATE/DELETE/INSERT statement is prefixed by WITH, or
+ * if there is a RETURNING with a *lot* of results. In those cases
+ * the portal will be busy until all results have been fetched, and will
+ * not be able to deliver results belonging to other parallel queries
+ * running on the same filedescriptor.
+ *
+ * However, considering that the current heuristic increases query-speed
+ * in the majority of the real-world cases, it would be considered a good
+ * tradeoff.
*/
private Regexp execfetchlimit
=iregexp("^\a*((UPDA|DELE)TE|INSERT)\a|\aLIMIT\a+[1-9][; \t\f\r\n]*$");
--
GitLab