All, > I'm not sure what the solution is. This scenario is going to be a problem > for any system which tries to judge future usage based on past usage. If > the infrequent query with a strict response time requirement is infrequent > enough any automatic algorithm will evict it.
The way Greg puts this it sounds extremely hypothetical, but it's actually pretty common. For example, I had an application which was primarily data entry but periodically (one per 10 minutes or so) would run a heavy-duty full-text search. This caused the full-text index to go to disk alot ... but since the data entry was employees and the FTS was for customers, we'd have rather had the FTI "pinned" in memory and the data entry be 50% slower. (in the end, we solved the issue with a ramdisk but that was a bit of a hack and involved spending $$$ on RAM) Mind you, that's a case of needing to have an *index* pinned, but I think those are just as common. Overall, it's a problem of having applications where response time is *not* tied to frequency of usage. -- Josh Berkus PostgreSQL @ Sun San Francisco ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
