Re: O_DIRECT in freebsd - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: O_DIRECT in freebsd
Date
Msg-id 200306222228.h5MMSFR27910@candle.pha.pa.us
Whole thread Raw
In response to Re: O_DIRECT in freebsd  (Sean Chittenden <sean@chittenden.org>)
Responses Re: O_DIRECT in freebsd  (Sean Chittenden <sean@chittenden.org>)
Re: O_DIRECT in freebsd  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Sean Chittenden wrote:
> > What you really want is Solaris's free-behind, where it detects if a
> > scan is exceeding a certain percentage of the OS cache and moves the
> > pages to the _front_ of the to-be-reused list.  I am not sure what
> > other OS's support this, but we need this on our own buffer manager
> > code as well.
> > 
> > Our TODO already has:
> > 
> >     * Add free-behind capability for large sequential scans (Bruce)
> > 
> > Basically, I think we need free-behind rather than O_DIRECT.
> 
> I suppose, but you've already polluted the cache by the time the above
> mentioned mechanism kicks in and takes effect.  Given that the planner
> has an idea of how much data it's going to read in in order to
> complete the query, seems easier/better to mark the fd O_DIRECT.
> *shrug*

_That_ is an excellent point.  However, do we know at the time we open
the file descriptor if we will be doing this?  What about cache
coherency problems with other backends not opening with O_DIRECT?  And
finally, how do we deal with the fact that writes to O_DIRECT files will
wait until the data hits the disk because there is no kernel buffer cache?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 


pgsql-hackers by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: O_DIRECT in freebsd
Next
From: Tom Lane
Date:
Subject: Re: PlPython