From: | Christopher Browne <cbbrowne(at)acm(dot)org> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: seq scan cache vs. index cache smackdown |
Date: | 2005-02-15 19:04:49 |
Message-ID: | m3hdkdod9q.fsf@knuth.knuth.cbbrowne.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
In the last exciting episode, merlin(dot)moncure(at)rcsonline(dot)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/>
From | Date | Subject | |
---|---|---|---|
Next Message | lcham02 | 2005-02-15 19:15:55 | disagreeing query planners |
Previous Message | Magnus Hagander | 2005-02-15 18:41:26 | Re: seq scan cache vs. index cache smackdown |