> [] 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 

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.

Takayuki Tsunakawa

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to