Hi,
I have played with this patch, it works fine.
rem the last position of the "new" total_time column is confusing
+CREATE VIEW pg_stat_statements AS
+ SELECT *, total_plan_time + total_exec_time AS total_time
+ FROM pg_stat_statements(true);
I wanted to perform some benchmark between those 4 cases:
0 - no pgss,
1 - original pgss (no planning counter and 1 access to pgss hash),
2 - pggs reading querytext in planner hook (* 2 accesses to pgss hash),
3 - pggs reading querytext in parse hook (* 3 accesses to pgss hash)
It seems that the difference is so tiny, that there was no other way than
running
minimal "Select 1;" statement ...
./pgbench -c 10 -j 5 -t 500000 -f select1stmt.sql postgres
case avg_tps pct_diff
0 89 278 --
1 88 745 0,6%
2 88 282 1,1%
3 86 660 2,9%
This means that even in this extrem test case, the worst degradation is less
than 3%
(this overhead can be removed using pg_stat_statements.track_planning guc)
notes:
- PostgreSQL 12devel on x86_64-w64-mingw32, compiled by gcc.exe
(x86_64-win32-sehrev1, Built by MinGW-W64 project) 7.2.0, 64-bit,
- cpu usage was less that 95%,
- avg_tps is based on 3 runs,
- there was a wait of arround 1 minute between each run to keep
computer temperature and fan usage low.
Regards
PAscal
--
Sent from: http://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html