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

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