| From: | pgsql(dot)spam(at)vinz(dot)nl |
|---|---|
| To: | pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Mount options for Ext3? |
| Date: | 2003-01-25 23:21:54 |
| Message-ID: | 20030125232154.GK14898@md2.mediadesign.nl |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
On 2003-01-24 21:58:55 -0500, Tom Lane wrote:
> The key assumption we are making about the filesystem's behavior is that
> writes scheduled by the sync() will occur before the pg_control write
> that's issued after it. People have occasionally faulted this algorithm
> by quoting the sync() man page, which saith (in the Gospel According To
> HP)
>
> The writing, although scheduled, is not necessarily complete upon
> return from sync.
>
> This, however, is not a problem in itself. What we need to know is
> whether the filesystem will allow writes issued after the sync() to
> complete before those "scheduled" by the sync().
>
Certain linux 2.4.* kernels (not sure which, newer ones don't seem to have
it) have the following kernel config option:
Use the NOOP Elevator (WARNING)
CONFIG_BLK_DEV_ELEVATOR_NOOP
If you are using a raid class top-level driver above the ATA/IDE core,
one may find a performance boost by preventing a merging and re-sorting
of the new requests.
If unsure, say N.
If one were certain his OS wouldn't do any re-ordering of writes, would it be
safe to run with fsync = off? (not that I'm going to try this, but I'm just
curious)
Vincent van Leeuwen
Media Design
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2003-01-26 01:00:22 | Re: copying perms to another user |
| Previous Message | Dave Cramer | 2003-01-25 22:46:38 | interactive docs error |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2003-01-26 05:27:51 | Re: [PERFORM] Proposal: relaxing link between explicit JOINs and execution order |
| Previous Message | Ron Johnson | 2003-01-25 19:19:09 | Re: LOCK TABLE & speeding up mass data loads |