Re: Planning counters in pg_stat_statements

From: pgsql-hackers-owner(at)postgresql(dot)org
> [mailto:pgsql-hackers-owner(at)postgresql(dot)org] On Behalf Of Thomas Munro
> I have often wanted $SUBJECT and was happy to find that Fujii-san had posted
> a patch five years ago[1]. The reception then seemed positive.
> So here is a refurbished and (hopefully) improved version of his patch with
> a new column for the replan count. Thoughts?

That's a timely proposal. I sometimes faced performance problems where the time pg_stat_statements shows is much shorter than the application perceives. The latest experience was that the execution time of a transaction, which consists of dozens of DMLs and COMMIT, was about 200ms from the application's perspective, while pg_stat_statements showed only about 10ms in total. The network should not be the cause because the application ran on the same host as the database server. I wanted to know how long the parsing and planning time was.

BTW, the current pg_stat_statement shows unexpected time for COMMIT. I expect it to include the whole COMMIT processing, including the long WAL flush and sync rep wait. However, it only shows the time for the transaction state change in memory.

Regards
Takayuki Tsunakawa