Re: O_DIRECT in freebsd

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, "Jim C(dot) Nasby" <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: O_DIRECT in freebsd
Date: 2003-06-23 02:46:56
Message-ID: 20030623024656.GK97131@perrin.int.nxad.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> > Basically, I think we need free-behind rather than O_DIRECT.
>
> There are two separate issues here --- one is what's happening in
> our own cache, and one is what's happening in the kernel disk cache.
> Implementing our own free-behind code would help in our own cache
> but does nothing for the kernel cache.
>
> My thought on this is that for large seqscans we could think about
> doing reads through a file descriptor that's opened with O_DIRECT.
> But writes should never go through O_DIRECT. In some scenarios this
> would mean having two FDs open for the same relation file. This'd
> require moderately extensive changes to the smgr-related APIs, but
> it doesn't seem totally out of the question. I'd kinda like to see
> some experimental evidence that it's worth doing though. Anyone
> care to make a quick-hack prototype and do some measurements?

What would you like to measure? Overall system performance when a
query is using O_DIRECT or are you looking for negative/postitve
impact of read() not using the FS cache? The latter is much easier to
do than the former... recreating a valid load environment that'd let
any O_DIRECT benchmark be useful isn't trivial.

-sc

--
Sean Chittenden

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2003-06-23 02:57:41 Re: Two weeks to feature freeze
Previous Message Bruce Momjian 2003-06-23 02:45:06 Re: O_DIRECT in freebsd