On Tue, Feb 28, 2012 at 12:30 AM, Stefan Keller <sfkeller@xxxxxxxxx> wrote: > > Thank you for the tipp. > Making slave pgsql run on persistent RAM filesystem is surely at least > a possibility which I'll try out. > > But what I'm finally after is a solution, where records don't get > pushed back to disk a.s.a.p. but rather got hold in memory as long as > possible assuming that there is enough memory. That is already the case. There are two separate issues, when dirty data is written to disk, and when clean data is dropped from memory. The only connection between them is that dirty data can't just be dropped, it must be written first. But have written it, there is no reason to immediately drop it. When a checkpoint cleans data from the shard_buffers, that now-clean data remains in shared_buffers. And at the OS level, when an fsync forces dirty data out to disk, the now-clean data generally remains in cache (although I've seen nfs implementations where that was not the case). It is hard to figure out what problem you are facing. Is your data not getting loaded into cache, or is it not staying there? Cheers, Jeff -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
