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

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

 



Guy Thornley wrote:
> > >> I thought that posix_fadvise() with POSIX_FADV_WILLNEED was exactly
> > >> meant for this purpose?
> > > 
> > > This is a good idea - I wasn't aware that this was possible.
> > 
> > This possibility was the reason for me to propose it. :-)
> 
> posix_fadvise() features in the TODO list already; I'm not sure if any work
> on it has been done for pg8.2.
> 
> Anyway, I understand that POSIX_FADV_DONTNEED on a linux 2.6 kernel allows
> pages to be discarded from memory earlier than usual. This is useful, since
> it means you can prevent your seqscan from nuking the OS cache.
> 
> Of course you could argue the OS should be able to detect this, and prevent
> it occuring anyway. I don't know anything about linux's behaviour in this
> area.

We tried posix_fadvise() during the 8.2 development cycle, but had
problems as outlined in a comment in xlog.c:

    /*
     * posix_fadvise is problematic on many platforms: on older x86 Linux
     * it just dumps core, and there are reports of problems on PPC platforms
     * as well.  The following is therefore disabled for the time being.
     * We could consider some kind of configure test to see if it's safe to
     * use, but since we lack hard evidence that there's any useful performance
     * gain to be had, spending time on that seems unprofitable for now.
     */

-- 
  Bruce Momjian   bruce@xxxxxxxxxx
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +


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

  Powered by Linux