Re: Allowing WAL fsync to be done via O_SYNC

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Justin Clift <aa2(at)bigpond(dot)net(dot)au>, Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Allowing WAL fsync to be done via O_SYNC
Date: 2001-03-16 01:04:11
Message-ID: 16474.984704651@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> For example, Tom had a nice fsync test program. Why can't we run that
> on various platforms and collect the results, then make a decision on
> the best default.

Mainly because (a) there's not enough time before release, and (b) that
test program was far too stupid to give trustworthy results anyway.
(It was assuming exactly one commit per XLOG block, for example.)

> Trying to test the affects of fsync() with a database wrapped around it
> really makes for difficult measurement anyway.

Exactly. What I'm doing now is providing some infrastructure with which
we can hope to see some realistic tests. For example, I'm gonna be
leaning on Great Bridge's lab guys to rerun their TPC tests with a bunch
of combinations, just as soon as the dust settles. But I'm not planning
to put my faith in only that one benchmark.

I'm all for improving the intelligence of the defaults once we know
enough to pick better defaults. But we don't yet, and there's no way
that we *will* know enough until after we've shipped a release that has
these tuning knobs and gotten some real-world results from the field.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Warner 2001-03-16 01:08:01 Re: Performance monitor signal handler
Previous Message Justin Clift 2001-03-16 01:02:39 Testing structure (was) Re: Allowing WAL fsync to be done via O_SYNC