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
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 |