Re: RAM-only temporary tables
От | Kevin Grittner |
---|---|
Тема | Re: RAM-only temporary tables |
Дата | |
Msg-id | 4926ED5C.EE98.0025.0@wicourts.gov обсуждение исходный текст |
Ответ на | Re: RAM-only temporary tables (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: