Re: Large tables (was: RAID 0 not as fast as

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Postgresql General]     [Postgresql PHP]     [PHP Users]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Yosemite]

  Powered by Linux