The intuitive thing would be to put pg into a file system. 


On Thu, 21 Oct 2004 12:44:10 +0200, Leeuw van der, Tim
> 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
> 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:
> ---------------------------(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



---------------------------(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

Reply via email to