The intuitive thing would be to put pg into a file system. /Aaron
On Thu, 21 Oct 2004 12:44:10 +0200, Leeuw van der, Tim <[EMAIL PROTECTED]> wrote: > Hi, > > 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) > > cheers, > > --Tim > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Steinar H. Gunderson > Sent: Thursday, October 21, 2004 12:27 PM > To: [EMAIL PROTECTED] > 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 > -- Regards, /Aaron ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
