Tom Lane wrote: > James Rogers <[EMAIL PROTECTED]> 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 [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
