Re: How to speed up the first-time-searching in pgsql?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Smith <gsmith(at)gregsmith(dot)com>
Cc: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, zxo102 ouyang <zxo102(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: How to speed up the first-time-searching in pgsql?
Date: 2009-05-27 01:43:01
Message-ID: 23958.1243388581@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Greg Smith <gsmith(at)gregsmith(dot)com> 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Scott Marlowe 2009-05-27 01:48:34 Re: How to speed up the first-time-searching in pgsql?
Previous Message Greg Smith 2009-05-27 01:24:03 Re: How to speed up the first-time-searching in pgsql?