Re: Postgresqlism & Vacuum?

From: The Hermit Hacker <scrappy(at)hub(dot)org>
To: Thomas Reinke <reinke(at)e-softinc(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Postgresqlism & Vacuum?
Date: 2000-04-14 19:06:23
Message-ID: Pine.BSF.4.21.0004141605360.2807-100000@thelab.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 ...

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2000-04-14 19:11:43 Re: PRIMARY KEY
Previous Message Charles Tassell 2000-04-14 18:21:02 Re: Postgresqlism & Vacuum?