Re: Postgresqlism & Vacuum?
От | The Hermit Hacker |
---|---|
Тема | Re: Postgresqlism & Vacuum? |
Дата | |
Msg-id | Pine.BSF.4.21.0004141605360.2807-100000@thelab.hub.org обсуждение исходный текст |
Ответ на | Re: Postgresqlism & Vacuum? (Thomas Reinke <reinke@e-softinc.com>) |
Список | 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 по дате отправления: