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
