Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TEODx-0006D8-EO for pgsql-admin@postgresql.org; Wed, 19 Sep 2012 17:38:09 +0000 Received: from cerberus.pinpointresearch.com ([66.7.238.130] helo=polaris.pinpointresearch.com) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1TEODu-000056-R8 for pgsql-admin@postgresql.org; Wed, 19 Sep 2012 17:38:08 +0000 Received: from [192.168.1.179] (betelgeuse.pinpointresearch.com [192.168.1.179]) by polaris.pinpointresearch.com (Postfix) with ESMTP id F3A91E00EC83 for ; Wed, 19 Sep 2012 10:38:03 -0700 (PDT) Message-ID: <505A02FB.60206@pinpointresearch.com> Date: Wed, 19 Sep 2012 10:38:03 -0700 From: Steve Crawford User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120827 Thunderbird/15.0 MIME-Version: 1.0 To: pgsql-admin@postgresql.org Subject: Re: Postgres Cache usage References: <1348072617.30485.YahooMailNeo@web163805.mail.gq1.yahoo.com> In-Reply-To: <1348072617.30485.YahooMailNeo@web163805.mail.gq1.yahoo.com> Content-Type: multipart/alternative; boundary="------------000607040902010602090605" X-Pg-Spam-Score: -2.5 (--) X-Archive-Number: 201209/104 X-Sequence-Number: 40045 This is a multi-part message in MIME format. --------------000607040902010602090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/19/2012 09:36 AM, A J wrote: > Hi, > I have a read heavy application. I would want it to read from memory > as database latency has to be in low milliseconds. > The database is not too big in size and can be fully contained in memory. > > With Postgres, if I cache all the tables (by pre-emptive querying such > as select * from tables); is it assured that all subsequent queries > that have involved where clauses made up of several indexed fields > will still hit the cache (unless data is refreshed by writes) ? > > Example if my first query is select * from table1. Then if my second > query is "select * from table1 where (field1 between v1 and v2) and > (field2 between v3 and v4)"; would the second query read from the cache ? > > Thanks. Probably, mostly. But the planner won't use an index for the first query but hopefully will on the second and the index may not be cached. If you have enough RAM and nothing contending for it then the OS will probably cache appropriately. But there are other optimizations you may want to consider like turning off atime on your disk (for Linux, in any case) to avoid requiring a write for every read. For simple read queries the connection setup time will become an issue so connection-pooling and persistent connections will be useful. Cheers, Steve --------------000607040902010602090605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/19/2012 09:36 AM, A J wrote:
Hi,
I have a read heavy application. I would want it to read from memory as database latency has to be in low milliseconds.
The database is not too big in size and can be fully contained in memory.

With Postgres, if I cache all the tables (by pre-emptive querying such as select * from tables); is it assured that all subsequent queries that have involved where clauses made up of several indexed fields will still hit the cache (unless data is refreshed by writes) ?

Example if my first query is select * from table1. Then if my second query is "select * from table1 where (field1 between v1 and v2) and (field2 between v3 and v4)"; would the second query read from the cache ?

Thanks.

Probably, mostly. But the planner won't use an index for the first query but hopefully will on the second and the index may not be cached. If you have enough RAM and nothing contending for it then the OS will probably cache appropriately.

But there are other optimizations you may want to consider like turning off atime on your disk (for Linux, in any case) to avoid requiring a write for every read.

For simple read queries the connection setup time will become an issue so connection-pooling and persistent connections will be useful.

Cheers,
Steve

--------------000607040902010602090605--