From: | legrand legrand <legrand_legrand(at)hotmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Planning counters in pg_stat_statements (using pgss_store) |
Date: | 2019-04-01 20:35:19 |
Message-ID: | 1554150919882-0.post@n3.nabble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2019-04-01 20:37:06 | Re: pgsql: Compute XID horizon for page level index vacuum on primary. |
Previous Message | Tom Lane | 2019-04-01 20:22:31 | Re: Fix XML handling with DOCTYPE |