Are you able to take some 'perf top' during high CPU spike and see what's burning CPU there? Though the issue is related to blocking, but high CPU spikes may hint some spinning to acquire behavior.
Will do, although hopefully the spikes were only growing pains after the upgrade.
If your previous relation size is smaller than after upgrade, that's a signal that you do have holes in relation, thus extension can be avoided sometimes for new tuples.
The relation between high CPU and page splits is not immediately obvious to me.
We run with synchronous_commit off, but there does seem to be a peak in I/O requests around the CPU spikes.
Is a page split by nature a synchronous I/O activity? And do the other connections wait in some kind of CPU intensive form (like a spinlock?)
Kind regards, Andomar -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
