On Thu, 25 May 2006, Andrew Morton wrote:
Wu Fengguang <[email protected]> wrote:
These are nice-looking numbers, but one wonders. If optimising readahead
makes this much difference to postgresql performance then postgresql should
be doing the readahead itself, rather than relying upon the kernel's
ability to guess what the application will be doing in the future. Because
surely the database can do a better job of that than the kernel.
That would involve using posix_fadvise(POSIX_FADV_RANDOM) to disable kernel
readahead and then using posix_fadvise(POSIX_FADV_WILLNEED) to launch
application-level readahead.
Has this been considered or attempted?
Postgres chooses not to try and duplicate OS functionality in it's I/O
routines.
it doesn't try to determine where on disk the data is (other then
splitting the data into multiple files and possibly spreading things
between directories)
it doesn't try to do it's own readahead.
it _does_ maintain it's own journal, but depends on the OS to do the right
thing when a fsync is issued on the files.
yes it could be re-written to do all this itself, but the project has
decided not to try and figure out the best options for all the different
filesystems and OS's that it runs on and instead trust the OS developers
to do reasonable things instead.
besides, do you really want to have every program doing it's own
readahead?
David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
