From: pgsql-hackers-owner@postgresql.org
> [mailto:pgsql-hackers-owner@postgresql.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
shorterthan the application perceives. The latest experience was that the execution time of a transaction, which
consistsof dozens of DMLs and COMMIT, was about 200ms from the application's perspective, while pg_stat_statements
showedonly about 10ms in total. The network should not be the cause because the application ran on the same host as
thedatabase 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
changein memory.
Regards
Takayuki Tsunakawa
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers