Re: About the default performance

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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073