SEO
vBulletin Search Engine Optimization
| |||||||
| Register | FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
04-18-2008, 11:08 AM
| ||||
| ||||
 Re: seq scan cache vs. index cache smackdown > It seems inevitable that Postgres will eventually eliminate that redundant > layer of buffering. Since mmap is not workable, that means using O_DIRECT > to > read table and index data. What about going the other way and simply letting the o/s do all the caching? How bad (or good) would the performance really be? Merlin ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings      |
|
04-18-2008, 11:08 AM
| ||||
| ||||
| Re: seq scan cache vs. index cache smackdown In the last exciting episode, merlin.moncure@rcsonline.com ("Merlin Moncure") wrote: >> It seems inevitable that Postgres will eventually eliminate that >> redundant layer of buffering. Since mmap is not workable, that >> means using O_DIRECT to read table and index data. > > What about going the other way and simply letting the o/s do all the > caching? How bad (or good) would the performance really be? I'm going to see about taking this story to OLS (Ottawa Linux Symposium) in July and will see what hearing I can get. There are historically some commonalities in the way this situation is regarded, in that there was _long_ opposition to the notion of having unbuffered disk devices. If there's more "story" that definitely needs to be taken, let me know... -- output = reverse("moc.enworbbc" "@" "enworbbc") http://linuxdatabases.info/info/slony.html Rules of the Evil Overlord #90. "I will not design my Main Control Room so that every workstation is facing away from the door." <http://www.eviloverlord.com/> |
Linear Mode
