> Are you sure you properly cleared out the stats between profiling sessions? > Also, XLogFlush gets called by background processes like autovac, > checkpointer and bgwriter, in addition to being called by committing > processes. If one profiled session contained a checkpoint and other did > not, or one just idled a lot longer between when the benchmark finished and > when you shutdown the server, perhaps that explains it. > > Anyway, I don't see this behavior change when turning on wal_debug and > looking in the logfiles for 'xlog flush request' messages.
Yes I did reset the stats between profiling sessions. Yes, probably XLogFlush()'s done by other processes were not considered by me. Also, after doing a few more runs (used pgbench -j 4 -c 32 -T 60) and observing results, I think I am getting convinced there is no surprise in getting XLogFlush() being called more often. Since, the patch enables backends to return more quickly from XLogFlush() in more number of cases than before, which in turn causes them to proceed to further transactions which again call XLogFlush(). So, the increased number of XLogFlush() should be accounted for by increase in throughput that we see. In earlier mail, it might have been wrong of me to conclude that the throughput rise and rise in #invocations of XLogFlush() are not proportional. I think they are, though not rigorously as far as I could measure. I am wondering if this line of interpreting it is correct? -- Amit Langote -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
