Greg Smith <gsmith@xxxxxxxxxxxxx> writes: > On Tue, 26 May 2009, Scott Marlowe wrote: >> Also, in the morning, have a cron job crank up that does "select * from >> mybigtable" for each big table to load it into cache. > Just to clarify: on 8.3 and later versions, doing this doesn't do what > some people expect. Sequential scans like that will continuously re-use a > 256KB section of the PostgreSQL shared_buffers space, so this won't cause > all of that to get paged back in if the problem is related to it being > swapped out. It will pass everything through the OS buffer cache though > and prime it usefully, which might be all that's actually needed. Bearing in mind that this is a Windows server ... I seem to recall that the conventional wisdom is still to keep shared_buffers relatively small on Windows. So priming the OS cache is exactly what it's about. (Keeping that down should also help avoid the other scenario Scott was worried about, where shared memory itself gets paged out.) regards, tom lane -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
