Re: Postgresqlism & Vacuum? - Mailing list pgsql-general

From The Hermit Hacker
Subject Re: Postgresqlism & Vacuum?
Date
Msg-id Pine.BSF.4.21.0004141605360.2807-100000@thelab.hub.org
Whole thread Raw
In response to Re: Postgresqlism & Vacuum?  (Thomas Reinke <reinke@e-softinc.com>)
List pgsql-general
On Fri, 14 Apr 2000, Thomas Reinke wrote:

>
>
> Stephen J Lombardo wrote:
> >
> > >
> > > Why save on micro-seconds to use sequential scan when the table is small and
> > > later 'forgets' that the table is now big because you didn't vacuum analyze?
> > > Why can't the optimizer just use indexes when they are there and not
> > > 'optimize' for special cases when the table is small to save micro-seconds?
> >
>
> [snip]
>
> >     You can be confident that the fine PostgreSQL developers have done a
> > good job with the optimizer. There are reasons that things are done the way
> > they are, but they might not be immediatly apparent.
> >
>
> That's all fine and good. But the bottom line is that the vacuum
> requirements,
> and the amount of time it takes, is a major drawback to the viability of
> PostGres in a commercial environment.  I have _never_ seen anybody
> like it. I have seen lots of work arounds; lots of gripes; lots
> of code developed to get around its problems (at least in our shop).
>
> Without suggesting _how_ to fix it, I think it is safe to
> say everyone would love to see it fixed. Personally,
> if someone were to give me an option of having a slower
> db engine (e.g. half the speed), but one that never had
> to be vacuumed short of a corruption of data, I would
> take the slower system. Simply because I can tolerate
> a transaction taking 1 second as opposed to 0.5 seconds.
> I cannot tolerate taking the system off-line for an hour at
> a time. Nor am I thrilled with the work we've had to put
> in to get around vacuum's problems.

Okay, I'm confused here .. if you don't vacuum, you will have that slower
db engine ... so just don't vacuum?

> So, my idea for the development team, assuming that there
> is no easy elegant solution to keeping performance optimal
> AND getting rid of the vacuum requirements: Provide a config
> option that allows an admin to select a fast database with
> regularly scheduled vaccuums, or a slower database with no
> vacuum requirements at all. (I'd take the latter.)

vacuum have to be run manually, not automatic ... so that option already
exists ...



pgsql-general by date:

Previous
From: Charles Tassell
Date:
Subject: Re: Unsupported frontend protocol? & config systems files?
Next
From: Colin Smith
Date:
Subject: Re: [Fwd: [HACKERS] Porting reports (cont'd)]