From: | Hannu Krosing <hannu(at)krosing(dot)net> |
---|---|
To: | Gavin Sherry <swm(at)linuxworld(dot)com(dot)au> |
Cc: | Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>, Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: ANALYZE after restore |
Date: | 2002-04-03 07:59:16 |
Message-ID: | 1017820759.2058.10.camel@rh72.home.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Clift | 2002-04-03 08:16:11 | Re: ANALYZE after restore |
Previous Message | Justin Clift | 2002-04-03 07:59:14 | Re: Re : Solaris Performance - Profiling (Solved) |