I guess the difference is in 'severe hacking inside PG' vs. 'some unknown amount of 
hacking that doesn't touch PG code'.

Hacking PG internally to handle raw devices will meet with strong resistance from 
large portions of the development team. I don't expect (m)any core devs of PG will be 
excited about rewriting the entire I/O architecture of PG and duplicating large 
amounts of OS type of code inside the application, just to try to attain an unknown 
performance benefit.

PG doesn't use one big file, as some databases do, but many small files. Now PG would 
need to be able to do file-management, if you put the PG database on a raw disk 
partition! That's icky stuff, and you'll find much resistance against putting such 
code inside PG.
So why not try to have the external FS know a bit about PG and it's directory-layout, 
and it's IO requirements? Then such type of code can at least be maintained outside 
the application, and will not be as much of a burden to the rest of the application.

(I'm not sure if it's a good idea to create a PG-specific FS in your OS of choice, but 
it's certainly gonna be easier than getting FS code inside of PG)



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steinar H. Gunderson
Sent: Thursday, October 21, 2004 12:27 PM
Subject: Re: [PERFORM] Anything to be gained from a 'Postgres Filesystem'?

On Thu, Oct 21, 2004 at 08:58:01AM +0100, Matt Clark wrote:
> I suppose I'm just idly wondering really.  Clearly it's against PG
> philosophy to build an FS or direct IO management into PG, but now it's so
> relatively easy to plug filesystems into the main open-source Oses, It
> struck me that there might be some useful changes to, say, XFS or ext3, that
> could be made that would help PG out.

This really sounds like a poor replacement for just making PostgreSQL use raw
devices to me. (I have no idea why that isn't done already, but presumably it
isn't all that easy to get right. :-) )

/* Steinar */
Homepage: http://www.sesse.net/

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

Reply via email to