Re: Database Kernels and O_DIRECT

Tom Lane wrote:
> James Rogers <jamesr(at)best(dot)com> writes:
> > If we suddenly wanted to optimize Postgres for performance the way
> > Oracle does, we would be a lot more keen on the O_DIRECT approach.
>
> This isn't ever going to happen, for the simple reason that we don't
> have Oracle's manpower. You are blithely throwing around the phrase
> "database kernel" like it would be a small simple project. In reality
> you are talking about (at least) implementing our own complete
> filesystem, and then doing it over again on every platform we want to
> support, and then after that, optimizing it to the point of actually
> being enough better than the native facilities to have been worth the
> effort. I cannot conceive of that happening in a Postgres project that
> even remotely resembles the present reality, because we just don't have
> the manpower; and what manpower we do have is better spent on other
> tasks. We have other things to do than re-invent the operating system
> wheel. Improving the planner, for example.

One question is what a database kernel would look like? Would it
basically mean just taking our existing portability code, such as for
shared memory, and moving it into a separate libary with its own API?
Don't we almost have that already?

I am just confused what would be different? I think the only major
difference I have heard is to bypass the OS file system and memory
management. We already bypass most of the memory management by using
palloc.

--
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