Tom,
> This analysis is nonsense, because PG does not rely on WAL for
> transaction rollback, and the amount of WAL activity is *not*
> proportional to transaction length. (At least not since 7.1.2.)
<snip>
> However, until you drop
> your focus on the WAL we'll not find out what's really the
> bottleneck...
Sorry, Tom. I was used to the problems of 7.1.2, and didn't really
"get it" when you told me things had changed.
I still say it's the disk I/O, and I think your explanation of dead
tuples makes a lot of sense. The debug log is full of this:
DEBUG: proc_exit(0)
DEBUG: shmem_exit(0)
DEBUG: exit(0)
DEBUG: reaping dead processes
DEBUG: child process (pid 11933) exited with exit code 0
DEBUG: proc_exit(0)
DEBUG: shmem_exit(0)
DEBUG: exit(0)
DEBUG: reaping dead processes
DEBUG: child process (pid 11939) exited with exit code 0
And each one of the cycles about takes 5-10 minutes.
I'm a little reluctant to dump everything to the list, as we're talking
about a lot of data and code. Lemme do some judicious editing and I'll
send you a gzip package this week.
-Josh Berkus