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