On Thu, 16 Jan 2003, Fred Zellinger wrote:
> With Oracle, you can screw around with files and tablespaces and
> extents and segments and partition striping and local and global
> indexing and block sizes and 400+ other tuning parameters to your
> heart's content. ... I am a control freak and I think a lot of
> other people are too. Oracle is tremendously complex and has a
> steep learning curve, but it gives me control. With PG, a lot
> of effort has been made to simplify. ... If PostgreSQL were to
> open up all the internals of storage and become as complex as
> Oracle, there probably would be a lot of high profile crashes and PG
> would get a bad reputation. However, I think that having a mode of
> operation(controlled at compile time) where all the dirty details of
> storage was made accessible in the data dictionary, would be something
> good to pacify the control freaks.
The reason you don't have all of these storage parameters available to
you, and they can't be "opened up" is that they simply aren't there.
Oracle uses raw devices and does all of its own management of disk space
at the block level. Postgres relies on the filesystem and the operating
system to deal with block allocation and a lot of the I/O scheduling.
Adding an effecient layer to replace this is a major project that would
probably provide few gains, since operating systems have gotten a lot
smarter about block allocation and I/O scheduling over the years. There
has been some discussion about this before, if you look back in the
archives.
There are various other places in postgres that the coders could work
on that are likely to provide more performance gain for less effort.
The optimizer comes to mind. At the low level, dropping shared memory
and moving to mmap might (but it's not certain) provide some noticable
improvement for not too much implementation effort.
cjs
--
Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're
alllight. --XTC
