Re: About the default performance

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.
> 
> > 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: , 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.
> 
>