On Sun, 24 Feb 2019 at 15:24, Tom Lane <[email protected]> wrote:
> I haven't attempted any performance measurements on this, but at
> least in principle it should speed things up a bit, especially
> for complex test cases involving longer Lists. I don't have any
> very suitable test cases at hand, anyway.
I've not yet looked at the code, but I thought I'd give this a quick benchmark.
Using the attached patch (as text file so as not to upset the CFbot),
which basically just measures and logs the time taken to run
pg_plan_query. Using this, I ran make installcheck 3 times unpatched
and same again with the patch. I pulled the results of each run into a
spreadsheet and took the average of each of the 3 runs then took the
sum of the total average planning time over the 20334 individual
results.
Results patched atop of 067786cea:
Total average time unpatched: 0.739808667 seconds
Total average time patched: 0.748144333 seconds.
Surprisingly it took 1.13% longer. I did these tests on an AWS
md5.large instance.
If required, I can send the entire spreadsheet. It's about 750 KB.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index 8b4d94c9a1..437256a35f 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -21,6 +21,7 @@
#include <fcntl.h>
#include <limits.h>
+#include <time.h>
#include <signal.h>
#include <unistd.h>
#include <sys/socket.h>
@@ -965,7 +966,15 @@ pg_plan_queries(List *querytrees, int cursorOptions,
ParamListInfo boundParams)
}
else
{
+ clock_t start, end;
+
+ start = clock();
+
stmt = pg_plan_query(query, cursorOptions, boundParams);
+
+ end = clock();
+
+ elog(LOG, "PlannerTime: %f", (double)(end - start) /
CLOCKS_PER_SEC);
}
stmt_list = lappend(stmt_list, stmt);
