Re: Planning counters in pg_stat_statements (using pgss_store)

On Mon, Apr 1, 2019 at 10:35 PM legrand legrand
<legrand_legrand(at)hotmail(dot)com> wrote:
>
> I have played with this patch, it works fine.

Thanks for testing!

> 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);

Yes, there are quite a lot of fields in pg_stat_statements(), so I
added the total_time as the last field to avoid enumerating all of
them. I can change that if needed.

> 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)

Is the difference between 2 and 3 the extraneous pgss_store call to
always store the query text if planner hook doesn't have access to the
query text?