Mark Stier wrote:
> Hi,
>
> I just wonder if it would be possible to speed up postgresql a bit if it
> wouldn't use files but partitions for data storage.
>
> That could also lead to the next generation of highly complex file systems that
> more seamlessly integrate into grpahical UIs.
>
> Regards,
>
> Mark
>
> p.s.: please don't hang me high for this one :-)
I think that the Un*x filesystem is one of the reasons that large database vendors
rather use raw devices, than filesystem storage files.
Using a raw device on the disk gives them the possibility to have complete control
over their files, indices and objects without being bothered by the operating
system. This speeds up things in several ways :
- the least possible OS intervention
- choose block sizes according to applications
- reducing fragmentation
- packing data in nearby cilinders
- Anyone other ideas -> the sky is the limit here
It also aids portability, at least on platforms that have an equivalent of a raw
device.
It is also independent of the standard implemented Un*x filesystems, for which you
will have to pay extra if you want to take extra measures against power loss.
The problem with e.g. e2fs, is that it is not robust enough if a CPU fails. This
is due
to the memory caching of i-nodes. For this the program update runs every (what?)
seconds,
but this is no true panacea. Of course, there are other filesystems for Linux, but
I
won't go out hunting for them and installing them. I have other things to do.
With the above scheme, the database vendor can design the internal file system, so
that there
is no data loss in case of a power failure.
Jurgen Defurne
defurnj@glo.be
