2010/10/13 Ron Mayer <rm_pg@xxxxxxxxxxxxxxxxxxxxxxx>: > Kevin Grittner wrote: >> >> ...Sybase named caches...segment off portions of the memory for >> specific caches... bind specific database >> objects (tables and indexes) to specific caches. ... >> >> When I posted to the list about it, the response was that LRU >> eviction was superior to any tuning any human would do. I didn't >> and don't believe that.... >> >> FWIW, the four main reasons for using it were: >> (1) Heavily used data could be kept fully cached in RAM... > > Lightly-used-but-important data seems like another use case. > > LRU's probably far better than me at optimizing for the total > throughput and/or average response time. But if there's a > requirement: > "Even though this query's very rare, it should respond > ASAP, even at the expense of the throughput of the rest > of the system." > it sounds like this kind of hand-tuning might be useful. it is exactly one of the purpose of pgfincore : http://villemain.org/projects/pgfincore#load_a_table_or_an_index_in_os_page_cache > > > -- > Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-performance > -- Cédric Villemain 2ndQuadrant http://2ndQuadrant.fr/ ; PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
