"scott.marlowe" <scott.marlowe@ihs.com> writes:
> Note that this is a good thing (TM) since it frees the postgresql
> development team to do other things than worry about caching 1 gig of
> data.
Yeah. I think this is one very fundamental difference of design
philosophy between Postgres and more-traditional databases such as
Oracle. We prefer to let the kernel and filesystem do their jobs,
and we assume they will do them well; whereas Oracle wants to bypass
if not replace the kernel and filesystem. Partly this is a matter of
the PG project not having the manpower to replace those layers. But
I believe the world has changed in the last twenty years, and the Oracle
approach is now obsolete: it's now costing them design and maintenance
effort that isn't providing much return. Modern kernels and filesystems
are *good*, and it's not easy to do better. We should focus our efforts
on functionality that doesn't just duplicate what the OS can do.
This design approach shows up in other areas too. For instance, in
another thread I was just pointing out that there is no need for our
frontend/backend protocol to solve communication problems like dropped
or duplicated packets; TCP does that perfectly well already.
regards, tom lane
