Re: Planning counters in pg_stat_statements (using pgss_store) - Mailing list pgsql-hackers

From legrand legrand
Subject Re: Planning counters in pg_stat_statements (using pgss_store)
Date
Msg-id 1554150919882-0.post@n3.nabble.com
Whole thread Raw
In response to Re: Planning counters in pg_stat_statements (using pgss_store)  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: Planning counters in pg_stat_statements (using pgss_store)
List 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fix XML handling with DOCTYPE
Next
From: Thomas Munro
Date:
Subject: Re: C_C_A animal on HEAD gets stuck in initdb