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 of the first concepts I learned in CS grad school was that of
optimizing a system at multiple levels. If the hardware guys can build
a 2X faster CPU, and the operating system guys can find a 2X improvement
in (say) filesystem performance, and then the application guys can find
a 2X improvement in their algorithms, you've got 8X total speedup, which
might have been impossible or at least vastly harder to get by working
at only one level of the system. The lesson for Postgres is that we
should not be trying to beat the operating system guys at their own
game. It's unclear that we can anyway, and we can certainly get more
bang for our optimization buck by working at system levels that don't
correspond to operating-system concerns.
I tend to agree with the opinion that Oracle's architecture is based on
twenty-year-old assumptions. Back then it was reasonable to assume that
database-specific algorithms could outperform a general-purpose
operating system. In today's environment that assumption is not a given.
regards, tom lane
