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.
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.)
Cheers, Thomas
--
------------------------------------------------------------
Thomas Reinke Tel: (905) 331-2260
Director of Technology Fax: (905) 331-2504
E-Soft Inc. http://www.e-softinc.com
Publishers of SecuritySpace http://www.securityspace.com
