From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: O_DIRECT in freebsd |
Date: | 2003-10-30 03:56:39 |
Message-ID: | 87ism7fkeg.fsf@stark.dyndns.tv |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Manfred Spraul <manfred(at)colorfullife(dot)com> writes:
> One problem for WAL is that O_DIRECT would disable the write cache -
> each operation would block until the data arrived on disk, and that might block
> other backends that try to access WALWriteLock.
> Perhaps a dedicated backend that does the writeback could fix that.
aio seems a better fit.
> Has anyone tried to use posix_fadvise for the wal logs?
> http://www.opengroup.org/onlinepubs/007904975/functions/posix_fadvise.html
>
> Linux supports posix_fadvise, it seems to be part of xopen2k.
Odd, I don't see it anywhere in the kernel. I don't know what syscall it's
using to do this tweaking.
This is the only option that seems useful for postgres for both the WAL and
vacuum (though in other threads it seems the problems with vacuum lie
elsewhere):
POSIX_FADV_DONTNEED attempts to free cached pages associated with the
specified region. This is useful, for example, while streaming large
files. A program may periodically request the kernel to free cached
data that has already been used, so that more useful cached pages are
not discarded instead.
Pages that have not yet been written out will be unaffected, so if the
application wishes to guarantee that pages will be released, it should
call fsync or fdatasync first.
Perhaps POSIX_FADV_RANDOM and POSIX_FADV_SEQUENTIAL could be useful in a
backend before starting a sequential scan or index scan, but I kind of doubt
it.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-10-30 03:58:30 | Re: Fwd: Re: Call for port reports |
Previous Message | Philip Yarra | 2003-10-30 00:30:24 | Fwd: Re: Call for port reports |