Tom Lane wrote:
> James Rogers <jamesr@best.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@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