Ron, This thread is getting on my nerves. Your tone in some of the other posts (as-well-as this one) is getting very annoying. Yes, PostgreSQL's storage manager (like all other open source databases), lacks many of the characteristics and enhancements of the commercial databases. Unlike Oracle, Microsoft, etc., the PostgreSQL Global Development Group doesn't have the tens of millions of dollars required to pay hundreds of developers around the world for round-the-clock development and R&D. Making sure that every little tweak, on every system, is taken advantage of is expensive (in terms of time) for an open source project where little ROI is gained. Before you make a statement like, "I wanted to verify that pg's IO rates were inferior to The Competition", think about how you'd write your own RDBMS from scratch (in reality, not in theory).
As for your question regarding developer docs for the storage manager and related components, read the READMEs and the code... just like everyone else. Rather than posting more assumptions and theory, please read through the code and come back with actual suggestions. -Jonah 2005/10/5, Ron Peacetree <[EMAIL PROTECTED]>: > First I wanted to verify that pg's IO rates were inferior to The Competition. > Now there's at least an indication that someone else has solved similar > problems. Existence proofs make some things easier ;-) > > Is there any detailed programmer level architectual doc set for pg? I know > "the best doc is the code", but the code in isolation is often the Slow Path > to > understanding with systems as complex as a DBMS IO layer. > > Ron > > > -----Original Message----- > From: "Joshua D. Drake" <[EMAIL PROTECTED]> > Sent: Oct 5, 2005 1:18 PM > Subject: Re: [HACKERS] [PERFORM] A Better External Sort? > > > The source is freely available for your perusal. Please feel free to > point us in specific directions in the code where you may see some > benefit. I am positive all of us that can, would put resources into > fixing the issue had we a specific direction to attack. > > Sincerely, > > Joshua D. Drake > > ---------------------------(end of broadcast)--------------------------- > TIP 9: In versions below 8.0, the planner will ignore your desire to > choose an index scan if your joining column's datatypes do not > match > -- Respectfully, Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation http://www.enterprisedb.com/ ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster