Thread: About the default performance
The problem is that people often benchmark the so called vanilla installation of PostgreSQL. I understand why the PostgreSQL team has decided to have an overly conservative default conf file. But no matter what the reason is or who's to blame that a tester has not tuned PostgreSQL configuration, the word is being spread that PostgreSQL is featurerich but _slow_. The ongoing discussion currently in performance list is just one example. I have seen it announce more than once: "we did not do any configuration tuning on the test systems". Take http://www.hwaci.com/sw/sqlite/speed.html as another example. "The PostgreSQL and MySQL servers used were as delivered by default on RedHat 7.2. (PostgreSQL version 7.1.3 and MySQL version 3.23.41.) No effort was made to tune these engines. Note in particular the the default MySQL configuration on RedHat 7.2 does not support transactions." I remember a discussion in the general list about having multiple default conf files to choose from. Ala low-end, average and high-end installations. A tool to read some system information and dynamically generating a proper configuration file was also mentioned. The other issue that a lot of new PostgreSQL users seem to have is the VACUUM ANALYZE. They just don't know about it. Perhaps some more active ones will read the documentation or ask for help in email lists. But a lot of them are surely leaving things and thinking of PostgreSQL as a slow system. Remember they too spread the word of their experience. I'm not an expert of PostgreSQL by any means I have just been reading PostgreSQL email lists for only about a month or so. So I believe I have read that there is a auto-vacuum being worked on? In my opinion this should be included in the main installation by default. This is just the kind of job that a machine should do...when a big portion of data has changed do VACUUM ANALYCE automagically. Is these improvements actually being implemented and how far are they? The technical side of these problems is not for this list of course. However the "side-effects" (reputation of being slow) of these problems direclty relate to advocacy and PostgreSQL popularity. Maybe these problems are already worked on or maybe I'm over exaggerating the situation but I do believe solving these issues would only benefit PostgreSQL. Just my 2 c Kaarel
Kaarel: (cross-posted back to Performance because I don't want to post twice on the same topic) > The problem is that people often benchmark the so called vanilla > installation of PostgreSQL. <snip> > I remember a discussion in the general list about having multiple > default conf files to choose from. Ala low-end, average and high-end > installations. A tool to read some system information and dynamically > generating a proper configuration file was also mentioned. Yes. So far, only Justin, Kevin B., Shridhar and I have volunteered to do any work on that task -- and all of us have been swamped with 7.4-related stuff. I would like to see, before the end of the year, some if not all of the stuff that Kaarel is posting about. Obviously, my first task is to set up a framework so that everyone can contribute to the project. > I'm not an expert of PostgreSQL by any means I have just been reading > PostgreSQL email lists for only about a month or so. So I believe I have > read that there is a auto-vacuum being worked on? In my opinion this > should be included in the main installation by default. This is just the > kind of job that a machine should do...when a big portion of data has > changed do VACUUM ANALYCE automagically. > > Is these improvements actually being implemented and how far are they? The auto-vacuum daemon (pgavd) is finished. However, it will still require the user to turn it on; we don't want to run potentially RAM-sucking background processes without user invitiation. So obviously that needs to be part of a comprehensive "quick start" guide. So, Kaarel .... you want to write the "quick start" guide for 7.4? All of the detail material is available online, you mainly need to provide narrative and links of the form of ... first, read this: <link>, then do this ... > The technical side of these problems is not for this list of course. > However the "side-effects" (reputation of being slow) of these problems > direclty relate to advocacy and PostgreSQL popularity. Maybe these > problems are already worked on or maybe I'm over exaggerating the > situation but I do believe solving these issues would only benefit > PostgreSQL. You're absolutely correct .... so let's do something about it. From my perspective, the first step is improved docs, becuase we can have those out by 7.4 release. -- Josh Berkus Aglio Database Solutions San Francisco
Hi everybody Is there any 'official' PostgreSQL banner? Greetings Conni
I'm willing to help too. I'm basically a DBA / developer type, with mild C hacking skills (I develop in PHP, so my C coding is quite rusty nowadays.) If nothing else testing on different equipment / OSes. On Fri, 4 Jul 2003, Josh Berkus wrote: > Kaarel: > > (cross-posted back to Performance because I don't want to post twice on the > same topic) > > > The problem is that people often benchmark the so called vanilla > > installation of PostgreSQL. > <snip> > > I remember a discussion in the general list about having multiple > > default conf files to choose from. Ala low-end, average and high-end > > installations. A tool to read some system information and dynamically > > generating a proper configuration file was also mentioned. > > Yes. So far, only Justin, Kevin B., Shridhar and I have volunteered to do any > work on that task -- and all of us have been swamped with 7.4-related stuff. > > I would like to see, before the end of the year, some if not all of the stuff > that Kaarel is posting about. Obviously, my first task is to set up a > framework so that everyone can contribute to the project. > > > I'm not an expert of PostgreSQL by any means I have just been reading > > PostgreSQL email lists for only about a month or so. So I believe I have > > read that there is a auto-vacuum being worked on? In my opinion this > > should be included in the main installation by default. This is just the > > kind of job that a machine should do...when a big portion of data has > > changed do VACUUM ANALYCE automagically. > > > > Is these improvements actually being implemented and how far are they? > > The auto-vacuum daemon (pgavd) is finished. However, it will still require > the user to turn it on; we don't want to run potentially RAM-sucking > background processes without user invitiation. So obviously that needs to be > part of a comprehensive "quick start" guide. > > So, Kaarel .... you want to write the "quick start" guide for 7.4? All of > the detail material is available online, you mainly need to provide narrative > and links of the form of ... first, read this: <link>, then do this ... > > > The technical side of these problems is not for this list of course. > > However the "side-effects" (reputation of being slow) of these problems > > direclty relate to advocacy and PostgreSQL popularity. Maybe these > > problems are already worked on or maybe I'm over exaggerating the > > situation but I do believe solving these issues would only benefit > > PostgreSQL. > > You're absolutely correct .... so let's do something about it. From my > perspective, the first step is improved docs, becuase we can have those out > by 7.4 release. > >
I can help with this too. --------------------------------------------------------------------------- scott.marlowe wrote: > I'm willing to help too. I'm basically a DBA / developer type, with mild > C hacking skills (I develop in PHP, so my C coding is quite rusty > nowadays.) > > If nothing else testing on different equipment / OSes. > > On Fri, 4 Jul 2003, Josh Berkus wrote: > > > Kaarel: > > > > (cross-posted back to Performance because I don't want to post twice on the > > same topic) > > > > > The problem is that people often benchmark the so called vanilla > > > installation of PostgreSQL. > > <snip> > > > I remember a discussion in the general list about having multiple > > > default conf files to choose from. Ala low-end, average and high-end > > > installations. A tool to read some system information and dynamically > > > generating a proper configuration file was also mentioned. > > > > Yes. So far, only Justin, Kevin B., Shridhar and I have volunteered to do any > > work on that task -- and all of us have been swamped with 7.4-related stuff. > > > > I would like to see, before the end of the year, some if not all of the stuff > > that Kaarel is posting about. Obviously, my first task is to set up a > > framework so that everyone can contribute to the project. > > > > > I'm not an expert of PostgreSQL by any means I have just been reading > > > PostgreSQL email lists for only about a month or so. So I believe I have > > > read that there is a auto-vacuum being worked on? In my opinion this > > > should be included in the main installation by default. This is just the > > > kind of job that a machine should do...when a big portion of data has > > > changed do VACUUM ANALYCE automagically. > > > > > > Is these improvements actually being implemented and how far are they? > > > > The auto-vacuum daemon (pgavd) is finished. However, it will still require > > the user to turn it on; we don't want to run potentially RAM-sucking > > background processes without user invitiation. So obviously that needs to be > > part of a comprehensive "quick start" guide. > > > > So, Kaarel .... you want to write the "quick start" guide for 7.4? All of > > the detail material is available online, you mainly need to provide narrative > > and links of the form of ... first, read this: <link>, then do this ... > > > > > The technical side of these problems is not for this list of course. > > > However the "side-effects" (reputation of being slow) of these problems > > > direclty relate to advocacy and PostgreSQL popularity. Maybe these > > > problems are already worked on or maybe I'm over exaggerating the > > > situation but I do believe solving these issues would only benefit > > > PostgreSQL. > > > > You're absolutely correct .... so let's do something about it. From my > > perspective, the first step is improved docs, becuase we can have those out > > by 7.4 release. > > > > > > > ---------------------------(end of broadcast)--------------------------- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faqs/FAQ.html > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073