From: | Ron Mayer <rm_pg(at)cheapcomplexdevices(dot)com> |
---|---|
To: | Luke Lonergan <llonergan(at)greenplum(dot)com> |
Subject: | Re: Large tables (was: RAID 0 not as fast as |
Date: | 2006-09-24 13:29:50 |
Message-ID: | 4516884E.6070308@cheapcomplexdevices.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Luke Lonergan wrote:
>
> I think the topic is similar to "cache bypass", used in cache capable vector
> processors (Cray, Convex, Multiflow, etc) in the 90's. When you are
> scanning through something larger than the cache, it should be marked
> "non-cacheable" and bypass caching altogether. This avoids a copy, and
> keeps the cache available for things that can benefit from it.
And 'course some file systems do this automatically when they
detect a sequential scan[1] though it can have unexpected (to some)
negative side effects[2]. For file systems that support freebehind
as a configurable parameter, it might be easier to experiment with
the idea there.
[1] http://www.ediaudit.com/doc_sol10/Solaris_10_Doc/common/SUNWaadm/reloc/sun_docs/C/solaris_10/SUNWaadm/SOLTUNEPARAMREF/p18.html
[2] http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6207772
From | Date | Subject | |
---|---|---|---|
Next Message | Ben | 2006-09-24 17:12:23 | IN not handled very well? |
Previous Message | Dave Cramer | 2006-09-23 14:19:34 | Re: Opteron vs. Xeon "benchmark" |