Re: O_DIRECT in freebsd

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Sean Chittenden <sean(at)chittenden(dot)org>
Cc: "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: O_DIRECT in freebsd
Date: 2003-06-22 22:28:15
Message-ID: 200306222228.h5MMSFR27910@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-22 22:29:07 Re: PlPython
Previous Message Sean Chittenden 2003-06-22 22:18:30 Re: O_DIRECT in freebsd