Re: tablespaces and non-empty directories

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>, Philip Yarra <philip(at)utiba(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tablespaces and non-empty directories
Date: 2005-11-23 04:16:16
Message-ID: 10220.1132719376@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
> Jim C. Nasby wrote:
>> Along those lines, is there anything else that would benefit from being
>> moved? pg_clog and pg_subtrans come to mind; but maybe pg_multixact and
>> pg_twophase are candidates as well?

> Hmm, I doubt moving any of the SLRU files (clog, subtrans, multixact)
> will have much of an impact.

Certainly pushing them onto the WAL spindle would be a serious misstep.
There is a good case for giving WAL its own dedicated disk --- there is
no case that I've seen for giving any of these their own disk.

> If there's too much I/O on those, a better
> solution would be to increase the number of buffers allocated to them.
> Currently we use 8 for all of them which is probably not appropiate for
> everyone.

I've just been looking at a test case provided by Rob Creager that
causes some pretty severe contention on SubtransControlLock. There
are a number of possible answers to this, but increasing the number of
pg_subtrans buffers is definitely one of them. I think it's probably
time we got rid of the assumption that all the uses of slru.c should
have the same number of buffers ...

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Christopher Kings-Lynne 2005-11-23 04:19:02 Re: Practical error logging for very large COPY
Previous Message Christopher Kings-Lynne 2005-11-23 04:16:01 Re: Practical error logging for very large COPY statements