Re: Perfomance Tuning

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: Perfomance Tuning
Дата
Msg-id 20030812050809.GC76772@home.samurai.com
обсуждение исходный текст
Ответ на Re: Perfomance Tuning  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Perfomance Tuning  ("scott.marlowe" <scott.marlowe@ihs.com>)
Re: Perfomance Tuning  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-performance
On Tue, Aug 12, 2003 at 12:52:46AM -0400, Bruce Momjian wrote:
 I don't use Linux and was just repeating what I had heard from others,
> and read in postings.  I don't have any first-hand experience with ext2
> (except for a laptop I borrowed that wouldn't boot after being shut
> off), but others on this mailing list have said the same thing.

Right, and I understand the need to answer users asking about
which filesystem to use, but I'd be cautious of bad-mouthing
another OSS project without any hard evidence to back up our
claim (of course if we have such evidence, then fine -- I
just haven't seen it). It would be like $SOME_LARGE_OSS
project saying "Don't use our project with PostgreSQL, as
foo@bar.org had data corruption with PostgreSQL 6.3 on
UnixWare" -- kind of annoying, right?

> > (a) ext3 does metadata-only journalling by default
>
> If that is true, why was I told people have to mount their ext3 file
> systems with metadata-only.  Again, I have no experience myself, but why
> are people telling me this?

Perhaps they were suggesting that people mount ext2 using
data=writeback, rather than the default of data=ordered.

BTW, I've heard from a couple different people that using
ext3 with data=journalled (i.e. enabling journalling of both
data and metadata) actually makes PostgreSQL faster, as
it means that ext3 can skip PostgreSQL's fsync request
since ext3's log is flushed to disk already. I haven't
tested this myself, however.

-Neil


В списке pgsql-performance по дате отправления:

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Perfomance Tuning
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Odd problem with performance in duplicate database