Re: ANALYZE after restore
От | Hannu Krosing |
---|---|
Тема | Re: ANALYZE after restore |
Дата | |
Msg-id | 1017820759.2058.10.camel@rh72.home.ee обсуждение исходный текст |
Ответ на | Re: ANALYZE after restore (Gavin Sherry <swm@linuxworld.com.au>) |
Ответы |
Re: ANALYZE after restore
|
Список | pgsql-hackers |
On Wed, 2002-04-03 at 06:52, Gavin Sherry wrote: > On Wed, 3 Apr 2002, Christopher Kings-Lynne wrote: > > > Hi, > > > > Would it be an idea to have pg_dump append an ANALYZE; command to the end of > > its dumps to assist newbies / inexperienced admins? > > I do not think this is desired behaviour. Firstly, pg_dump is not just for > restoring data to the system. Presumably another flag would need to be > added to pg_dump to prevent an ANALYZE being appended. Yes. > This is messing and, in my opinion, it goes against the 'does what it says> it does' nature of Postgres. What does pg_dump say it does ? Or should pg_dump append ANALYZE only if it determines that ANALYZE has been run on the database being dumped ? Do you have any tools that will break when ANALYZE is added, (and which don't break on the weird way of dumping foreign keys ;) ? > Secondly, in experienced admins are not going to get > experienced with database management unless they see that their database > runs like a dog and they have to read the manual. Rather they think that the database is indeed designed to run like a dog. For _forcing_ them newbies to learn we could append a new UNANALYZE command that inserts delibarately bogus info into pg_statistic to make it perform even worse by default ;) In general, I'd prefer a database that has no need to be explicitly maintained. How many experienced file-system managers do you know ? --------------------- Hannu
В списке pgsql-hackers по дате отправления: