5 ms·

once you start page faulting and hitting spinning disk it's game over for any database's performance, postgres included.

• yangyang 12y ago
  There are plenty of database that don't fit into RAM completely and are perfectly usable. It depends on what you can fit in buffer cache / OS page cache. The whole point of btree indexes is that they're efficient to query from disk.
• Nitramp 12y ago
  ... but that usually doesn't mean you have to have your full data set in memory, only the hot parts. And even if so, one or two ~10 ms seeks during a query aren't that terrible.
  • brey 12y ago
    mongodb recommends that your working set lives in memory, not your entire database - it's generally much cheaper to add more RAM than code in any case. a few seeks aren't terrible for small/medium applications, but when you're asking for thousands of queries a second any disk access is bad news.
• collyw 12y ago
  That sounds like bollocks. I have a script that grows a bit Perl hash. It fills up memory and starts paging. The application grinds to a halt (almost). I tie the hash to Berkly DB file, so it writes to disk. Performance is about a third of the in memory hash, BUT doesn't slow when it's too big for memory.