Re: Large tables (was: RAID 0 not as fast as - Mailing list pgsql-performance

From Bruce Momjian
Subject Re: Large tables (was: RAID 0 not as fast as
Date
Msg-id 200609220305.k8M35dI10346@momjian.us
Whole thread Raw
In response to Re: Large tables (was: RAID 0 not as fast as  (Guy Thornley <guy@esphion.com>)
Responses Re: Large tables (was: RAID 0 not as fast as  ("Jim C. Nasby" <jim@nasby.net>)
List pgsql-performance
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@momjian.us
  EnterpriseDB    http://www.enterprisedb.com

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

pgsql-performance by date:

Previous
From: Guy Thornley
Date:
Subject: Re: Large tables (was: RAID 0 not as fast as
Next
From: mark@mark.mielke.cc
Date:
Subject: Re: Large tables (was: RAID 0 not as fast as