Re: Analyze and vacuum, they are sort of mandatory....
От | Mark Woodward |
---|---|
Тема | Re: Analyze and vacuum, they are sort of mandatory.... |
Дата | |
Msg-id | 18847.24.91.171.78.1139752053.squirrel@mail.mohawksoft.com обсуждение исходный текст |
Ответ на | Re: Analyze and vacuum, they are sort of mandatory.... (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: Analyze and vacuum, they are sort of mandatory....
|
Список | pgsql-hackers |
> Mark Woodward wrote: >> I know this is a kind of stupid question, but postgresql does not >> behave well when the system changes in a major way without at least >> an analyze. There must be something that can be done to protect the >> casual user (or busy sometimes absent minded developer) from these >> dangerous edge conditions? > > autovacuum That's a good simple answer, sure, but it is no different than "run analyze," they are obvious when you know the problems, but not so when you don't are focusing on something else. I didn't see the "problem" because I didn't suspect HassHagg would behave so badly, who would? One of my biggest problems with Oracle is that there are so many ways that it can fail. One can argue that the DBA should "know what they are doing," and it is a good argument, but there is a diffeence between knowing the findimentals of server design, query design, parallel processing, I/O bandwidth, etc. and knowing the esoterica of a particular platform. One tends to acquire the essoterica as needed. What I discovered with PostgreSQL was a failure. It had run away memory cconsuption, this is bad behavior. On Linux it was killed, while I don't want to have that discussion, it is a real world fact that saying "turn OOM off," is not acceptable. If PostgreSQL exhibits bad behavior, it is PostgreSQL's problem. My question was based on an observation that ANALYZE and VACUUM are nessisary, both for different reasons. The system or tools must be able to detect substantial changes in the database and at least run analyze if failing to do so would cause PostgreSQL to fail badly.
В списке pgsql-hackers по дате отправления: