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                        |
  [EMAIL PROTECTED]               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to