Sorry for the late response; I was on vacation.
>>> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> wrote:
> Kevin, what was your original scenario like that led you to
investigate
> this?
We noticed a performance degradation in application code which, within
a database transaction, looped through large numbers of iterations
where each iteration created, used, and dropped a temporary table.
The temporary table always had several columns (typically ten to
twenty, many of which were varchar) and had a primary key.
We initially thought this was because of an upgrade of PostgreSQL from
8.2.5 to 8.3.4, but subsequent testing showed that it was because of
the concurrent update of the Linux kernel from one which defaulted to
not using write barriers to one which did default to using write
barriers. The file system was XFS on five spindles in RAID 5 on a
good BBU controller. Updating the relevant /etc/fstab entry with
nobarrier brought performance back to an acceptable level.
-Kevin