On Tue, Feb 28, 2012 at 11:15 AM, Tomas Vondra <tv@xxxxxxxx> wrote: > I haven't investigated why exactly the data are not cached initially, but > none of the options that I can think of could be "fixed" by setting > "fsync=off". That's something that influences writes (not read-only > database) and I don't think it influences how buffers are evicted from > shared buffers / page cache. > > It might speed up the initial load of data, but that's not what the OP was > asking. It speeds a lot more than the initial load of data. Assuming the database is read-only, but not the filesystem (ie: it's not a slave, in which case all this is moot, as you said, there are no writes on a slave). That is, assuming this is a read-only master, then read-only queries don't mean read-only filesystem. Bookkeeping tasks like updating catalog dbs, statistics tables, page cleanup, stuff like that can actually result in writes. Writes that go through the WAL and then the filesystem. With fsync=off, those writes happen on the background, and are carried out by the OS. Effectively releasing postgres from having to wait on them, and, assuming there's enough RAM, merging repeated writes to the same sectors in one operation in the end. For stats, bookkeeping, and who knows what else, the merging would be quite effective. With enough RAM to hold the entire DB, the merging would effectively keep everything in RAM (in system buffers) until there's enough I/O bandwidth to transparently push that to persistent storage. In essence, what was required, to keep everything in RAM for as much as possible. It *does* in the same way affect buffer eviction - it makes eviction *very* quick, and re-population equally as quick, if everything fits into memory. -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
