Hi, On Mon, 2007-11-12 at 09:12 +0000, Heikki Linnakangas wrote:
> Just leave it to the cache management algorithms in Postgres and > Linux. If it really is frequently accessed, it should stay in > Postgres shared buffers. How is "frequently accessed" determined by PostgreSQL? I mean... You know, OS caches either inodes, or pages. Page caches are pretty ignorable, since it means the data is already in virtual memory. So, we have inode caching, and IIRC it results in i/o requests from the disk -- and sure, it uses i/o scheduler of the kernel (like the all of the applications running on that machine -- including a basic login session). *If* the data hadn't been deleted, it returns from i/o scheduler. So there is no 100% guarantee that the table is in the memory. If we could use the ram (some (or a :) ) database(s) can do that IIRC), we will avoid i/o scheduler, which will really speed up the process. (Ok, AFAIK, you can "pin" your objects to memory with Oracle). ... and one more thing with ramfs: Since there is a fs on ramfs, it passes through VFS -- and goes through kernel schedulers again. So, IMHO, saying "trust your OS + PostgreSQL" is not a 100% perfect approach for the people who are asking to keep their objects on RAM, even though I know that there is nothing we can say right now. Regards, -- Devrim GÜNDÜZ , RHCE PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: plPHP, ODBCng - http://www.commandprompt.com/
signature.asc
Description: This is a digitally signed message part
